How to bolster vulnerability management with DevSecOps

Defining DevSecOps

DevSecOps is the set of tools and practices that enable an organization to introduce security as a requirement at the start of the software development pipeline and delivery cycle.

The DevSecOps model views security as equally important as meeting application goals and adhering to compliance policies. By making security everyone's responsibility -- from design through coding to testing and deployment -- DevSecOps reduces the risk that security problems will creep into software and go undetected until it's too late.

DevSecOps' goal is to foster team thinking to eliminate vulnerabilities. While some organizations might make an individual or small team responsible for DevSecOps tools and practices, their role should be to coordinate, not act as the sole practitioner of vulnerability management. In most successful DevSecOps implementations, the teams supporting the development pipeline provide the majority of resources.

DevSecOps best practices for vulnerability management

Due to the dispersed nature of DevSecOps, following established practices and procedures is critical. Every step in the pipeline must be hardened to minimize overall risk and avoid introducing new vulnerabilities by failing to adopt best practices. Document everything with clear delineation of roles and optimal tool support throughout the software development lifecycle (SDLC).

Improve security with SDLC modernization

The first step in DevSecOps adoption is securing the SDLC itself so that vulnerabilities aren't introduced through poor organization and control of development, testing and deployment. Most organizations should start by using modern tools and paradigms -- such as GitOps, containers and Kubernetes -- at each step. Don't begin to consider specialized DevSecOps tools or procedures until lifecycle processing is up to date.

Focus on modern tools, because development pipelines, rapid development and similar initiatives designed to reduce the lag between initiating a software change and releasing it to production have themselves created risks. Sloppy procedures can permit minimally tested -- or even untested -- software to progress through the pipeline. Without a strong, tool-enforced methodology at each stage, it's difficult to ensure teams use DevSecOps practices and tools properly.

Adopt specialized tools for vulnerability management

If modern development pipelines were enough to eliminate vulnerabilities on their own, there would be no need for DevSecOps. The next step is to introduce additional, vulnerability-focused security to the SDLC.

Look for DevSecOps tools in the following areas:

• SDLC monitoring, version control and development. If you can't get the right code into production, you can't control vulnerabilities. Seek out development tools that provide example code, reusable code snippets and version tracking.
• API management and documentation. The former promotes building APIs with greater security, and the latter helps ensure protective measures aren't lost in changes.
• Testing and test auditing. These tools evaluate code quality and vulnerabilities concurrently to performance and functionality.
• Production release management and pre-release validation. Representing an organization's last line of defense, these tools connect DevSecOps measures with real-world cyberthreats.

Regularly check code -- including libraries -- for vulnerabilities

Many organizations that adopt DevSecOps conduct code reviews -- for compliance or other reasons. For successful vulnerability management, add vulnerability analysis to these reviews. If your organization does not currently mandate such review, research existing code review tools and practices to find one that fits your organization, then initiate the requirement and train personnel on the process.

Library management is a critical element of DevSecOps in the development phase. Because successful exploits often mean a chance to break into multiple systems, hackers tend to work hard to attack library code. As a result, allowing developers to simply adopt software libraries is risky.

At minimum, developers should keep inventories of which libraries they use for all software, and organizations should assign a team member to monitor each library item for reported vulnerabilities. If more security is needed, introduce requirements to get permission to add a new library item to the inventory, and include a vulnerability status check and test for each. Specialized DevSecOps tools for software composition analysis are helpful here.

Testing for vulnerabilities vs. bugs

Testing is essential to DevOps, and DevSecOps is no exception. But in DevSecOps, it's important to differentiate between avoiding bugs and vulnerabilities.

Traditional software testing seeks to replicate user behavior by presenting all the data combinations for a given message set. However, when looking for vulnerabilities, developers should also include tests to handle unexpected structures, such as malformed messages, to increase the chances of detecting a vulnerability.

Dynamic application security testing imitates what a hacker might do when attempting to breach a system, rather than generating masses of test messages. Consequently, these tests could miss unusual attack vectors.

Interactive application security testing (IAST) tools validate APIs and web interfaces, monitor interactions to create model behaviors, and spot vulnerabilities missed in brute-force testing with random data. Some DevSecOps teams prefer to run these tests first and others last; the best strategy usually depends on the complexity of the interfaces. The more complex the interface or API, the more likely that early-stage IAST will be helpful.

Because libraries are a major source of vulnerabilities, code that includes library elements, particularly new ones, demands special attention. However, organizations in sectors that are frequent targets for hackers -- such as financial services, government and utilities -- should test all new code extensively for vulnerabilities.

Just how much special software is needed for DevSecOps is an open question. But few debate the importance of establishing a DevSecOps process, training all personnel along the SDLC in vulnerability management and conducting formalized security reviews -- usually facilitated by a central DevSecOps coordinator. Without these measures, rapid development can easily become an invitation to hacking.