Top 6 DevOps Web Application Security Best Practices

In today’s world, the importance of incorporating web application security best practices cannot be overstated. Recent studies show that web applications are the top attack vector in nearly 80% of incidents. The good news is DevOps processes lend themselves to integrated security practices. Here are the top six best practices for seamlessly weaving web application security into DevOps. 

The Role of Web Application Security Best Practices in DevOps 

The cornerstone of a successful DevOps practice is automation; this is why automating security within workflows (DevSecOps) makes so much sense. DevSecOps is lacing each step of the DevOps process and practice with security.  

By adding security into each step of the software development lifecycle (SDLC) – from planning to coding and building to testing to staging to operating and monitoring – the most important outputs of the SDLC are assured to be secure when deployed and attestable for compliance. Integrating security into each DevOps function effectively creates DevSecOps – an overarching layer covering all activity along the SDLC.  

We will dive into the top level of each best practice below, but if you are looking for further guidance, download The DevSecOps Playbook: Practical Steps for Producing Secure Software. 

Best Practice 1: Identify Your Attack Surface 

Fully discovering your sources of risk is a practice that kicks off the art of DevSecOps. You cannot secure what you do not know about. When conducting your search, keep an eye out for: 

• Different Application Types - Identify the entire portfolio, including micro-services and legacy, cloud-native, web, mobile, outsourced, and acquired apps. 

• Different Application Elements - Establish a complete inventory of applications, the first party code, their frameworks, additional third-party components, and their deployment artifacts.  

• Different Development Tools and Ecosystems - Discover which integrated developer environments (IDE), external dependencies, developer tools, languages, and frameworks are used or supported. You also want to know specific CI/CD pipeline systems and cloud environments which help map out Code, Build, and Deploy aspects of the SDLC (ex: Github Actions, Gitlab Pipelines, Azure Pipelines, Jenkins Pipelines). 

• Different Risk Levels - Understand which assets in your inventory carry the most risk (likelihood and impact) and have the most precious or valuable data. Consider threat modeling, but balance deep threat modeling exercises with understanding current risk state. This is done with scanning, and we will get into more detail on scanning in the next best practice.  

Gather information and make an inventory. It can be helpful in this practice to have an understanding of how you will prioritize based on what you find. In a perfect world, you are able to tackle everything at once, but how do you decide what becomes priority one if that is what resources allow? 

Schedule a demo of Veracode and a security pro will gladly assist you in determining prioritization based on your specific needs. Typical measures of prioritization seek to identify impact, (i.e. what data may be impacted), and likelihood of an incident; we can assist with this. 

Best Practice 2: Know What’s in Your Sources of Risk 

Once you have discovered and inventoried applications, you want to know what is in them by performing scans with a vulnerability scanning tool. Whether in the code you wrote in house, or in the third party libraries you may be using, you will get an initial snapshot where some potential issues may lie.  

A few tools that are easily integrated into the SDLC are: 

• Static Application Security Testing (SAST) - Scanning source or binary code in a-pre-production or “static” state to find security flaws or CWEs. Also called “white box” testing. 

• Container Security – Scanning containers to find Infrastructure as Code (IaC) configuration risks and secrets exposure.  

• Software Composition Analysis (SCA) - Analyzing the open-source libraries and third-party components in an application for CVEs. Used in the creation of Software Bill of Materials (SBOM) and supports one or both standard formats: CycloneDX and SPDX. 

By onboarding and scanning applications via integration and automation, you are laying the foundation for a more secure — and cost effective — application lifecycle. 

A word to the wise: claims about SAST can be misleading. Some vendors claim to do SAST, but they are primarily looking at IaC configurations and secrets. You will notice in the above description that SCA is not the same thing as testing first party code. Many vendors do not even test source code or application binaries themselves. That is why, at Veracode, we pride ourselves as being an organization that continues to research and add coverage beyond expectation. Veracode scans binaries and has support for nearly 40 languages and hundreds of frameworks. 

Best Practice 3: Define and Assign Security Policies Based on Risk Tolerance 

Policy is a mechanism for risk and compliance objectives to be communicated effectively to development. Without it, you are unable to manage risk and compliance because there is no signal between the roles.  

Having a common policy sets clear expectations and rules with which applications must comply. It is a complex task that should include security, development, and even board level input on qualifying risk tolerance so a policy can be set. 

Via technical controls in the CI/CD process, you can establish a continuous feedback loop that monitors compliance with policies and ensures that if code drifts from policy – or if any new flaws are created – teams are alerted, and the violations can be addressed. 

When scanning with Veracode, you can use Veracode’s built-in security policies recommendations for applications based on business criticality. You can also tailor them and restrict findings by severity, CWE category, CWE ID, license risk, Common Vulnerability Scoring System (CVSS) score, or a common standard such as OWASP, OWASP Mobile, CWE Top 25, or Precast/Prestressed Concrete Institute Security Standards Council (PCI SSC). 

Since Veracode is built in an auto-scaling cloud environment, Veracode always ensures that our customers have all the computation resources needed to perform testing effectively and comprehensively. As such, Veracode fully tests applications giving a full view of risk. Yet policy becomes a filter in which the meaning of policy compliance is clearly and unambiguously conveyed to the engineering team. 

Best Practice 4: Triage and Address Security Flaw Findings 

Web application security does not stop at just finding flaws. To measurably reduce risk, we must fix those findings. When it comes to DevSecOps, in both old and new applications, the goals are: 

1. To understand the backlog of existing security debt and begin to manage security risk off the backlog. 

2. To prevent net new risk by actively scanning for it and responding to it on a schedule or upon an event like a new build. 

You need a plan for tackling the security flaws in older, legacy applications to meet compliance. The good news is that time spent fixing security flaws can be massively reduced with artificial intelligence security flaw remediation technology.  

Leveraging a GPT-based machine learning model trained on Veracode’s proprietary dataset, Veracode Fix is a specialized AI that excels at fixing insecure code and dramatically reduces the work and time needed to remediate flaws. This makes it possible to tackle massive amounts of Fix-able technical debt that would not otherwise be addressed.  

Best Practice 5: Iterate and Improve on Your Continuous and Measured Program 

Ideally, your web application security program will look different on day one, day one hundred, and day one thousand. It is something that must be nurtured and grown (or matured) into. Leverage reporting and analytics from your testing platform in order to iterate and improve your program. 

The right platform will have reports available on-demand so you can see the real-time status and health of the application security program. Using this information you can identify areas for improvement, set quantitative goals, and track progress against those goals.  

Really consider who you decide to partner with in your efforts. Their experience makes a difference. Experience builds up in raw ability to cover more application landscape and to help you on your journey. Reporting and analytics from the right vendor will give you the ability to provide compliance reporting (something easily comprehensible to attest to any auditor seeking attestation for compliance). 

Best Practice 6: Prevent New Flaws with Education and Engagement 

A secure coding culture helps prevent security flaws from entering code in the first place. Security is not just tooling; it is also about the mindset and education you engage development teams with.  

You can leverage reporting to track the nature of issues being introduced and identify skill gaps. This information can be used to design security programs and training curricula to target areas of concern. 

Web Application Security Best Practices Conclusion 

As DevOps landscape continues to evolve, remember that web application security best practices are an ongoing commitment. Embrace these best practices now, and you will be better equipped to produce secure software into the future. To keep learning about one of the most pivotal aspects, security culture, I write about how to engage developers to build a successful application security program in this blog.