DevSecOps uses policy to take the pressure off testing

In 2022, Black Duck commissioned the SANS Institute to investigate how firms are aligning their development, security, and operations teams with the organizational values, practices, and tools that compose the secure DevOps, or DevSecOps, approach.

In this series of blog posts, we'll look at what the SANS study can teach us about how implementing effective DevSecOps can help organizations institute secure coding without sacrificing development velocity, institute policies and testing to automate security, and help those involved with triage and remediation work more efficiently.

Let's start by looking at what the SANS study reveals about automating security testing and remediation, and setting policies as code.

Identifying important aspects of DevSecOps

When asked which elements they thought were crucial to their security programs, respondents identified shared security ownership as the most important. Increasing communication between the development, operations, and security teams was highlighted as a key to success by 56% of respondents, up from 51% in the 2021 results. Accordingly, 52% of respondents said ensuring developer buy-in was crucial, while 48% identified training developers on secure coding practices as vital to their program.

Effective DevSecOps depends on contributors owning their role in security, so developers who have a recognized role in an organization's security risk posture help ensure that a DevSecOps program does not underperform and an organization's risk does not rise.

A significant change in 2022 is that respondents appear to be increasingly convinced of the importance of automation. According to the SANS 2022 report, 55% of respondents thought that automating their build, test, deployment, and provisioning workflows was important, up from 43%, while 53% thought that integrating automated security testing into developer tools and workflows was important, up from 45%.

Continuous security testing is a key practice to secure DevOps. When the rates of software assets moving through the pipeline increase, more security testing will be needed. Automating application security testing (AST) throughout the software development life cycle (SDLC) is your best bet for increasing the success of your security program. DevOps integration reduces friction and moves security left in the workflow, helping firms uncover security risks sooner. Integration provides security risk insight at numerous points in the process, and automation offers the scalability, efficiency, and governance consistency required.

Understanding ASOC

Application security orchestration and correlation (ASOC) is a category of AppSec solution that uses process automation to accelerate vulnerability testing and mitigation. Data from diverse AppSec sources is gathered by ASOC solutions and combined into a single database. ASOC solutions then correlate findings and prioritize critical remediation efforts, enabling security teams to streamline their AppSec activities in an informed and efficient way.

The introduction of AI, machine learning, and other data science methodology and tools will improve DevSecOps, and the use of ASOC tools is likely to rise in the coming years. The SANS survey, however, reports that only 10% of organizations have fully integrated ASOC tools at this time, while 19% have partially done so. ASOC remains on the radar of 17% of organizations that report preliminary investigations, and 14% of organizations are experimenting or running pilot projects. Another 23% of respondents to the SANS study are unsure whether their company has made an investment in ASOC tools. And despite the potential of ASOC tools, 14% of organizations report that they are not investing in ASOC technologies at all.

Using policy-as-code to automate AppSec

Policy-as-code is a method of defining and managing security rules, criteria, and conditions using code and scripts. It programmatically establishes security gates in a continuous integration, continuous delivery, and continuous deployment (CI/CD) pipeline. It codifies guidelines for risk evaluation, response, and notification in application security testing, allowing security teams to automate testing workflows without sacrificing control or compromising on risk tolerance.

Writing policies in high-level programming languages enables security and DevOps professionals to quickly query them via the policy engine. Security checks and related security gates can be activated based on the specified criteria, depending on what they write in the policy script. Naturally, carrying out this task in the most technology-neutral manner attainable aids in scalability and resilience as best practices develop. This has made YAML and Python linchpins to policy-as-code.

Using policy-as-code to determine what testing tool should be used, or whether a test is needed in the application or environment, can streamline testing cycles and achieve greater accuracy and relevance in the results. This makes it possible to consistently and automatically enforce security policies, which eventually makes it possible to improve software quality without slowing down development.

Running the right test at the right time

When selecting the appropriate application security testing tool to use, it is important to consider the environment where the tool is deployed, the types of security issues it searches for, the programming languages the tool is compatible with, and the stage of the SDLC when testing is carried out. Most enterprises use a variety of technologies including interactive application security testing (IAST), dynamic application security testing (DAST), and static application security testing (SAST).

Organizations report using an average of 11 AST tools, and many report using more than two dozen. Although many technologies can be incorporated directly into DevOps pipelines, teams frequently struggle with complicated initial configurations and resulting changes to existing workflows. Automating extensive scans with every build can clog pipelines and overload developers with test results that may not relate to the job at hand.

Orchestrating application policy and testing solutions

Taking the pressure off your developers means finding a way to orchestrate your AST solutions so that your tools and processes work together and execute automatically. Application Security Orchestration and Correlation solutions integrate security tooling throughout the SDLC and connect development, operations, and security teams. Implementing orchestration solutions that use predefined criteria to assess the importance of code modifications, weigh overall risk score, and can be customized to your organization's security standards can help ensure that you're not slowing down your SLDC with unnecessary testing or burying your developers in irrelevant test results.

ASOC solutions also provide workflow and process management features that hasten risk mitigation in the SDLC by standardizing AST outputs, aggregating data from different security testing tools and data sources, getting rid of duplicate results, and assessing a vulnerability's severity and exploitability. This allows you to orchestrate all your AST tools with a single system of record that accounts for the policies you've specified, the application's unique profile, and what's changed in a sprint. This means you will run only the right tests to find and fix new issues. Security will link to your DevOps workflow and run parallel to it, allowing you to implement security without delaying the pipeline. You'll still extract and transmit vital insight at critical points without obstructing anything, and you'll still be able to take specific measures to construct deliberate security gates where needed.

That’s how you take the pressure off your teams tasked with setting policy and managing testing results. By providing them with ASOC tools to streamline policy-as-code and help them triage testing results, you empower them to manage risk proactively, focus on what matters most, and prioritize resources and activities based on business risk.