A Better Approach to DevSecOps

Most of the problems with DevSecOps today come back to organizations trying to “fix” security by adding testing at the end of the product cycle, hoping to catch some of the critical vulnerabilities. In this post, learn how to turn that around with an effective strategy to shift security testing to the earliest stages of development in support of DevSecOps.

In my previous post, I discussed SecDevOps and why it’s a better term than the commonly used DevSecOps. Security is often left as add-on or a gating process before releasing a product, but it’s difficult to fix security issues when a product is halfway out the door. Shifting security to the left, as in SecDevOps (which the more-common name DevSecOps doesn’t imply), is the key to success. Security must be part of each developer’s day-to-day workflow and integrated into the software pipeline.

As VP of Products here at Parasoft, my job is to make sure we are making this easier for our customers. What does this mean? Well to start, it means automating the shift-left of security controls and policies, to help our customers build security into the pipeline while reducing the impact and risk of DevSecOps. So how do you do it? Read more below to learn how to alleviate the traditional challenges of integrating security into DevOps. Then, we’ll inspect the DevSecOps workflow that successfully shift security to the left, where it should be.

Solving the challenges that prevent successful DevSecOps strategies

Most of the problems with DevSecOps today come back to organizations trying to “fix” security by adding testing at the end of the product cycle, hoping to catch some of the critical vulnerabilities. Here are some of the reasons how and why this is occurring, and how you can solve them with a smarter approach to security.

Challenge: Hard to know how to “fix” security

Most developers and testers are not security experts (yet!), so it is a tall order to be told to “fix” security in the late stages of development when it’s unclear what to do.

Solution: Improve security gradually

Instead, teams can use centralized policies, like secure coding standards and static analysis checks for common vulnerabilities, to improve security gradually over the whole development lifecycle. In addition, security tools can give developers and testers guidance on why vulnerabilities exist, how they are exploited, and ultimately, removed and tested. With Parasoft’s static analysis tools, you can easily define a centralized policy based on industry secure coding standards (i.e. CWE, OWASP, CERT, UL 2900). Documentation, examples, and embedded training are also built-in, to enable the entire team to keep learning what to do next.

Challenge: End-of-cycle security testing results in delays and vulnerabilities left in production

The common approach of attempting to shoe-horn security into an almost-complete product is insufficient. Too many vulnerabilities are making their way into production code.

Solution: Integrate security analysis into the earliest stages of development

Instead, security can be incorporated into day-to-day development and operations. Developers should be able to perform analysis directly inside the IDE, shifting security compliance to the very early stages of development. Parasoft tools integrate with the build process and provide CI plugins to verify that vulnerabilities stay out of the CI pipeline. Collected data is stored on a per-build bases and available to reporting and analytics dashboards.

Challenge: Unknown status of project security risk until the last moment

Lacking any sort of vulnerability assessment, projects have completely unknown security risks until some sort of testing is done. When late-cycle testing is done, security vulnerabilities discovered tend to cause late cycle churn and rework. Despite these heroic last-minute efforts, many security vulnerabilities still make it through into customers’ hands.

Solution: Ongoing monitoring of software quality and security

To enable prioritization and course correction, real-time compliance reporting should provide easy-to-access dashboards, with a top-level and deep-dive view of data. Parasoft eliminates the overhead of security oversight with highly customizable security dashboards, that are interactive, accessed from any location, and can be designed for any user, from developer to team lead to upper level manager.

Using Parasoft for a Smarter SecDevOps Workflow

If you understand the challenges above and you’re ready to get started, it starts with integrating testing tools into your existing development workflow. This is key to daily adoption and getting the most ROI from your investment. Let’s look at how Parasoft tools are integrated into a typical CI/CD pipeline and how they can be leveraged to “shift left” security in DevOps.

Here you see both pre-commit and post-commit in the workflow, with code analysis before and after submitting code to the source repository. Helping developers improve quality and security before code is checked in is a significant “shift left” advantage. Our tools start there, and then continue helping after code is checked in, built, and deployed.

Pre-commit workflow:

1. Decide on a security standard that suits the need of the project and organization (e.g. OWASP, CWE, CERT). Levels of compliance and composition of a coding standard, for example, can be customized to suit your needs and can be a combination of security and quality standards.
2. Encapsulate the security policy in a test configuration. This is usually done centrally, for an entire project, by a team lead.
3. Make defined configuration(s) available for developers to use when they are writing and testing their code. The key benefit here is getting these standards in place on every developer’s desktop environment, so everyone is working to the same standard.
4. Apply checkers to code before check in. Our experience has shown that the best practice is to not make compliance to the test configuration a gate to check in, as this will impact the team’s efficiency and adoption of secure coding practices. Code that isn’t fully compliant is often checked in for various reasons that tools can’t necessarily evaluate, and the purpose of the post-commit part of the workflow is to both perform a ‘complete analysis’ and act as the safety net.

Post-commit workflow:

1. Build code, run existing tests, and perform project-wide static analysis.
2. Inspect results published to the security dashboard, to determine areas of concern.
3. Analyze results, prioritize violations, and assign them accordingly, in the form of tasks for the appropriate developer. With Parasoft, instant feedback is available via pre-set and customizable dashboards.
4. Take actions to address the warnings and violations that are published and available in everyone’s IDE for review.

Building-in Security as part of Quality

Most software teams understand the need to deliver high-quality code, regardless of the maturity of their current process. Leveraging that existing mindset to improving security, you can intertwine security requirements, controls, and standards as part of your existing quality improvement process. At the dashboard level, viewing security compliance in real-time, with the ability to dig down into problem areas based on highlighted areas of concern, helps security become a part of everyday quality management.

Summary

It’s important to prioritize security as early as possible in the development lifecycle to “shift left” both enforcement of security standards and good practices, and successfully achieve DevSecOps. To enable this, you need an approachable and easy-to-adopt process to detect and remove vulnerabilities as soon code is written by developers. Parasoft’s real-time, customizable analysis and reporting dashboards provide instant feedback to team leads and security experts about the state of the project, its compliance to chosen standards, and exactly where the highest concerns are, so the whole organization can understand risks.