Application security refers to the practices and strategies that protect software applications from vulnerabilities, threats and unauthorized access so that organizations can ensure the confidentiality, integrity and availability of their application and its data.
AppSec’s primary goal centers on identifying and mitigating risks that can arise due to design flaws, coding errors or malicious attacks targeting the application. By applying security controls throughout the application’s development lifecycle, you can identify and address them as early as possible to minimize the potential impact on security.
At its core, application security is a people, process and technology problem. All too often, we focus our attention on the technology piece of AppSec, hoping that tools and automation will save us. But what if the tools and automation are part of our application’s attack surface?
To understand and address this problem, we first need to look at how AppSec has evolved.
Application Security from 2000-2015
Between 2005 and 2015, organizations moved away from desktop applications and toward web-based applications. As vulnerabilities like cross-site scripting (XSS), SQL injection and cross-site request forgery (CSRF) emerged, web application security became a hot topic.
To address these new vulnerabilities, security testing tools — such as static application security testing (SAST), dynamic application security testing (DAST) and interactive application security testing (IAST) — became more sophisticated and popular.
At the same time, the definition of AppSec expanded beyond perimeter-based security measures to capture the need for a more proactive and holistic approach to security. The OWASP Top 10 project reflected these changes and included new vulnerabilities. Insecure direct object references (IDOR) and CSRF made the 2007 OWASP list, for example.
2015 Onward: Secure Deployment in the Cloud Era
The migration to the cloud significantly changed the definition of AppSec. It now encompasses multiple areas — threat modeling and secure design, secure coding, incident response and a plethora of other forms of application security testing. One core component of AppSec, secure deployment, saw a complete overhaul.
Before 2015, the industry defined secure deployment as the implementation of secure deployment practices. This involved the secure configuration of servers and networks, secure transmission of data and proper access controls. While the definition served its purpose before organizations migrated to the cloud, we now need a new definition to modernize current practices and move away from an outdated approach to secure deployment.
But why do we need to rethink how we define secure deployment?
In traditional on-premises environments, organizations had full control over the infrastructure stack, including hardware, operating system and application layers. But in cloud computing, cloud service providers (CSPs) and cloud users operate within a shared responsibility model. The CSP assumes responsibility for securing the underlying infrastructure, while the cloud user remains responsible for securing their applications and data. This shift has transformed AppSec into a joint effort between customer and CSP.
Due to the shared nature of infrastructure and resources, cloud environments introduce a new attack surface. The cloud user’s applications and data can be vulnerable to attacks exploiting misconfigurations in the cloud environment or targeting other tenants. AppSec now needs to address not only traditional vulnerabilities but also cloud-specific threats and risks.
To address these new cloud-specific threats, we need to precisely define what counts as an application in our modern cloud environments.
Defining the Modern Application
The goal for modern AppSec remains the same — ensure that an organization’s applications adhere to the CIA triad. This triad combines the three key security principles of confidentiality, integrity and availability of high-value data, whether the data pertains to the customers or the organization.
Unfortunately, the definition of “application” isn’t as clear. What constitutes an application? Is it just the code we write, or does it include the third-party dependencies that developers leverage to accelerate time to market?
When we talk about the application lifecycle, we tend to overlook anything that isn’t directly part of the application. We forget about the tools and automation — even the people — that create and move the traditional “application” from conception to the cloud.
But overlooking components of the application lifecycle prevents organizations from taking a modern approach to cloud AppSec. Because the cloud threat landscape has changed dramatically — with a significant rise in attacks targeting the software supply chain — the way we define applications needs to also capture the full value stream of that application.
In practice, as we secure an application, we need to consider how each of its building blocks, including all application dependencies, work together to create a unique and valuable application. An application’s building blocks entail everything from proprietary and third-party code to the four Cs of cloud-native security — the code, the container, the cluster and the cloud.
But as we seek to modernize our approach to AppSec, we need to add a fifth “C” — the continuous integration and continuous delivery (CI/CD) pipeline.
CI/CD Pipelines: The Fifth “C” of Cloud-Native Security
All infrastructure and application code passes through a CI/CD pipeline, commonly used to streamline application development and deployment. An AppSec program will integrate security into this process by leveraging automated security testing, code analysis and vulnerability scanning tools.
Developers should treat security as code and build it into the development pipeline so they can detect and address security issues early in the development lifecycle. Additionally, security must protect the development pipeline. Both the OWASP Top 10 2021 edition and the OWASP Top 10 CI/CD Security Risks outline steps AppSec practitioners should take to adopt a more risk-centric approach to pipeline weaknesses and security misconfigurations.
Tips to Get Started with CI/CD Security
To protect your pipelines from potential vulnerabilities, threats and unauthorized access, you’ll need to adopt several best practices.
Secure access controls: Make sure to implement proper access controls to your CI/CD tools, repositories and infrastructure. Only authorized individuals should have access to the pipeline components. You’ll also need to enforce strong authentication mechanisms such as multifactor authentication.
Code and artifact integrity: Code and artifacts being deployed through the CI/CD pipeline need to be protected against tampering and unauthorized modifications. You can do this by implementing code signing, checksum verification, secure artifact repositories and other mechanisms.
Secure configuration management: Apply secure configuration practices to your CI/CD pipeline components, including build servers, version control systems and deployment tools. Regularly review and update configurations to align with security best practices and guidelines.
Automated security testing: Integrate automated security testing into your CI/CD pipeline to identify security vulnerabilities and weaknesses early in the development process. This may include static code analysis, DAST, software composition analysis (SCA) and vulnerability scanning.
Dependency management: Manage and secure third-party dependencies used in the application. Regularly update and patch dependencies to mitigate known vulnerabilities and reduce the risk of supply chain attacks.
Secrets management: Properly handle and protect sensitive information, such as API keys, credentials and encryption keys used in the CI/CD pipeline. Use secure storage and encryption mechanisms to safeguard secrets and minimize the risk of unauthorized access.
Modern AppSec for the Cloud
Now that we’ve expanded our definition of AppSec to include securing your CI/CD pipeline, one question remains. How would we approach application security if we could start from scratch?
Let’s walk through an analogy. Imagine you’re building a car — i.e., an application. Building a car is a complex process involving many engineers, designers and automation specialists who work together to ensure the car is secure and safe to drive. But you can’t drive the car if you don’t also have well-paved roads — i.e., CI/CD pipelines securely configured.
Given that you need safe and secure roads to drive a car, why build the car before we build the roads? And even if we build the most secure car and the most well-paved roads, have we taken the time to secure our destination — i.e., the cloud?
Application security is everything, and everything is application security. To secure our applications, we have to start by first securing the pipeline (i.e., the road) and then securing the cloud (i.e., our destination) so we can be confident that our application code is secure.
If you’re looking for more practical tips to help you protect your CI/CD pipelines, download the CI/CD Security Checklist.
