%20Icon.svg){kind=small}
Once upon a time in Application Security, times were simpler. Not long ago, security and development teams could simply scan their code for vulnerabilities and feel confident that their next software release would be secure. But no longer.
Updated: June 2024
The software development lifecycle (SDLC) has grown more complex and agile, and in the process, become enveloped by a complex web of people, processes and systems. The modern SDLC, increasingly called CI/CD pipelines for those adopting DevOps, is a larger and ever-changing attack surface that requires far more than code scanning – challenging AppSec to move in a new and uncharted direction in order to secure it.
In this blog we examine the evolution of application security and why securing the modern SDLC requires organizations to embrace new approaches to supply chain security, code to cloud security coverage and protection from modern threats.
SCA and SAST: A Focus on Code Scanning
The practice of code scanning has been around in some form for decades. Static Application Security Testing (SAST) and Software Composition Analysis (SCA) tools were introduced in the early 2000’s, and adoption has grown exponentially. These tools are now a common and critical component of today’s AppSec toolkit.
SAST tools scan source code that is written directly by development teams, while SCA tools scan for open-source software dependencies in source code and any vulnerabilities associated with them. Both scans take place in the pre-production environment, enabling teams to identify and remediate vulnerabilities without breaking builds or passing code-based vulnerabilities to production software.
However, these scans have serious limitations, including the fact that they often noisily create security issues without context, and don’t provide visibility into the entire software supply chain environment.
For example, many security teams take the results from SCA and SAST scanners and assign developers all critical vulnerabilities to fix. But what if fixing those vulnerabilities doesn’t impact the business or reduce the risk to the environment?
It’s not a matter of just prioritizing which vulnerabilities to fix first based on the CVSS score of the vulnerability. It’s also about assessing the business value of fixing vulnerabilities that are more risky because they impact high-value business applications that involve revenue, customer interactions, or sensitive data.
Modern Application Security: Many More Attack Vectors to Defend
In the past five years, the SDLC has shifted to high-speed, high-volume, continuous releases made possible through DevOps methodologies. Modern applications are built from hundreds to thousands of parts that make up the CI/CD pipeline including code libraries, code repositories, build servers, plug-ins, pipeline orchestrations, development/deployment artifacts, artifact registries, Infrastructure-as-Code, and much more.
This modern software supply chain now constitutes an enormous attack surface – and vulnerability. Cybercriminals have taken notice and we’ve seen with the rise of software supply chain attacks increasing 3-6x per year, and Gartner estimates that by 2025, 45% of all organizations will experience attacks on their software supply chain.
Remember the phrase, “you are only as strong as your weakest link? With thousands of attack vectors to defend, organizations are struggling to surface them with related context, prioritize remediation based on business criticality, and protect applications all the way from code to cloud. Bad actors have learned how to exploit the broader range of modern application security vulnerabilities, harming your organization and potentially others downstream.
More Than Scanning Code: Securing Applications Through the Modern SDLC
Organizations need broader visibility and context across this complex and dynamic attack surface. How can this be achieved? By thinking not only about securing code but also the systems/infrastructure, pipelines/processes, and people that span the pre-production environment from code to cloud. Let’s look at some of these components with examples of vulnerabilities in each.
SDLC systems/infrastructure
The use of development systems like Source Code Management (SCM) systems such as GitHub, build servers like Jenkins, and artifact registries such as JFrog are now commonplace. Unfortunately, it's also common for these systems to be misconfigured in a way that can open the door to tampering or IP theft across your source code, build configuration files, and software artifacts.
For example, GitHub is sometimes regarded as an “operating system” across an organization's development operations, where a single misuse can lead to critical incidents, data breaches, and software supply chain attacks. GitHub does not lack security features, but it can be difficult and time-consuming to consistently enforce security across large implementations, and GitHub misconfigurations are a very common source of vulnerabilities. Further, manually enforcing consistency across GitHub is very labor intensive and prone to human error.
GitHub is just one example. SDLC misconfiguration risks via SCMs, build servers, artifact registries, and more can lead to many dangerous exploits: denial of service attacks, maliciously changing your code, manipulating your CI/CD scripts, hijacking your production artifacts, stealing your secrets, and lateral movement into other critical assets.
Misconfigured build servers is a common problem that creates significant vulnerabilities. Build systems are essentially automated, implicitly trusted pathways straight to the cloud, yet most aren’t treated as critical from a security perspective. In many cases, these systems — like Jenkins, for example — are misconfigured or otherwise vulnerable and unpatched.
Processes
The CI/CD pipeline includes automated processes for efficient code management, compiling and building, and staging and deployment. There are many ways attackers can compromise a development pipeline or process at various stages. These include poisoning an upstream open-source repo or typosquatting (otherwise known as URL hijacking), compromising a container image repo, gaining access to a continuous integration server and making changes in the pipeline to incorporate malicious code, or gaining access to a source repo and exploiting a vulnerability in production.
A compromise at any of these phases can be difficult to identify and the downstream impact, as was seen with the SolarWinds attack and the many victims of it, can be devastating and far-reaching.
People
The LastPass attack was a reminder of the need to secure the people that access your organization’s pre-production development environment. As we saw with LastPass, it only takes one compromised account for a malicious actor to gain access to the entire SDLC.
A wide variety of people have permissions to access the source code management systems, CI/CD systems, and artifact registries that make up your software development processes. Each of these systems has a different permission model but are orchestrated together, and the complex infrastructure that underpins the SDLC makes it difficult to manage all the permissions a user may have. Add to that the fact that organizations often have a bad security habit of sharing credentials across systems, and you now have a large portion of your development team with powerful access to a large portion of your company’s SDLC.
This complex and untamed web of permissions creates an easy target for attackers. All hackers need to do is gain access to the right developer or account – either active or dormant - and they could obtain broad and powerful access to your build environment where they can wreak havoc, stealing IP and inflicting downstream damage to your customers.
Secrets in code
Secrets in code stems from an insecure development practice of leaving credentials and other sensitive date in code that then gets proliferated by systems and processes. Secrets are sensitive information stored in code repositories, such as tokens, passwords, and keys, that can be easily accessed throughout the build process. Secrets are pervasive, can easily fall into the wrong hands, and can provide attackers with broad access to APIs, and sensitive data, exposing you to threats.
Due to the nature of modern software development, secrets can easily make their way into your Git repository. Once there, they remain there forever, sitting in one or more of your commits, waiting to be found and used against you. Not only do the secrets sit in a Git server, but every clone and fork saves this secret on a different machine, often without the creator’s awareness of it. Once a secret is in your Git repository, it is usually hard to find all instances of it. Even on private repositories, one compromised account in your organization can lead to many secrets being leaked over time.
When using public repositories, a pushed secret can have immediate and dire ripple effects. Often by the time an exposed secret is found, it has already been picked up by automated bots, and the repository has been archived by multiple archiving tools. Unfortunately, that means you should consider it exposed and compromised from the first minute it was public.
Better Together: Extend SAST and SCA with Secure Application Delivery
SAST and SCA tools remain an important part of the AppSec toolkit, but it’s undeniable that they alone are insufficient to provide secure application delivery today. Ultimately, application security tools work more effectively and efficiently with a solid foundation underneath them.
An application security posture management (ASPM) platform adds software supply chain security, visibility across pre-production development environments, code to cloud traceability, and the ability to remediate security issues faster with greater context to SCA and SAST.
This gives teams a single view across the pre-production development environment, spanning risk scoring, correlation, and risk remediation. This information can also be used for governance and compliance of the software supply chain and the applications that pass through them. These capabilities are also timely with the arrival of related regulatory requirements such as Software Bill of Materials (SBOM), US Executive Order 14028, Secure Software Development Framework (SSDF), and security frameworks such as Supply Chain Levels for Software Artifacts (SLSA).
The Legit ASPM platform works seamlessly with existing SAST and SCA tools and your development processes to provide secure application delivery and continuous assurance that your software releases are secure.
To learn more about this new approach to application security, download our new whitepaper.
To learn more about the Legit platform, book a demo .