To ensure the security of modern applications, application APIs should be made inherently secure by validating the application logic before release. Software development teams need “developer-first” security tools that fit naturally into the developer workflow to find and prevent vulnerabilities before software reaches production.
Among the sessions in the Security track at GitHub Universe 2022 , I noticed two prominent themes. First, application security is largely developer-led. Grey Baker, VP of Product Management for security features at GItHub, stated “Developers are at the heart of application security.” Second, the “shift left” movement has unintended consequences for developers. These two seemingly opposing statements represent the crux of secure application development. While experts agree that finding and fixing security issues during development has numerous benefits, naively shifting additional responsibilities to a developer significantly impacts productivity. Instead, we need to provide developers with appropriate tools that assist, rather than burden, the development of secure applications.
APIs are an attack surface exploited by hackers
Modern applications with public APIs offer an attack surface for bad actors to exploit vulnerabilities in an application. A variety of runtime security products offer solutions to mitigate infrastructure, network, and stateless attacks, but fail to protect against exploits of the application logic that powers an API.
Vulnerabilities in an application’s business logic are introduced at development time, when a flawed piece of code is included in an application. The flawed code may originate from third-party code (such as OSS) or by proprietary “homegrown” code that implements certain application logic or glues together third-party software modules. In either case, the natural place to remediate these flaws is during development for a number of reasons. Identifying an issue before the developer switches context to another feature leads to a faster and easier fix. Moreover, fixing an issue in development before the software reaches production avoids unnecessary risk. As an industry, we must emphasize the importance of ensuring that applications are inherently secure, and reduce our reliance on runtime protections that are unable to detect and mitigate certain kinds of exploits.
Although the source of vulnerabilities motivates the “shift left” movement that has been underway for years, one must remember that developers are the integral element in the software development process. Both Leonid Stolyarov (KPMG UK) and Nick Liffen (GitHub) emphasized the criticality for security tooling that supports a developer to release new features. Any attempt to simply shift traditional security tools that have been traditionally used at the end of the software development lifecycle (SDLC) for point-in-time assessment to an earlier stage does not adequately address the developer experience, and will not lead to more secure applications. Traditional security tools were designed for security professionals. Developers, who are often not security experts, lack the knowledge to properly use the tools and are often overwhelmed by the volume or details in the output of the tools. Furthermore, the manual, human-operated usage model of these traditional tools does not fit into the developer’s workflow. Both of these drawbacks hinder developer productivity and can cause developers to find workarounds that lead to less secure code.
Software development teams need developer-first security tools
What software development teams need are “developer-first” security tools that fit naturally into the developer workflow to find and prevent vulnerabilities before software reaches production. Dependency scanners and tools for source code bill of materials (SBOM) have seen a sharp rise in adoption thanks in part to an emphasis on seamless integration with the developer experience. Yet, these alone are not sufficient for building secure applications because the tools only report about vulnerabilities found in third-party, open source software.
Our product, Aptori, autonomously tests an API to uncover flaws in the application logic which is a combination of code written in-house by developers and combined with third-party dependencies. Aptori is designed for developers to use in local development and CI/CD. It acts as a security companion that detects security issues and presents each issue with a cause and remedy that is easy to understand.