This is the second installment in a series about making DevSecOps work in your organization. In a previous post, we covered the first pillar of the DevSecOps model—discovery. In this post we discuss the second, which is validation. The reason this phase is so important to the DevSecOps model and for successful vulnerability management is that it’s the point where the software flaws that represent true risks are separated out from those that are not serious security risks.

The official definition of insight is “the capacity to gain an accurate and deep intuitive understanding of a person or thing.” Having complete insight into your application’s security risks is the key to making them secure and compliant. Most organizations look at application security risk in individual silos of their application architectures and not how individual components interact with each other within the application architecture.

Let’s face it – Application Programming Interfaces or APIs are a foundational part of modern applications. They are just as crucial as home-grown code, open-source packages, frameworks, and libraries in your application’s architecture. One of the questions I have heard for years while working with commercial enterprise applications is: do you have an API?

This is the first installment in a series about making DevSecOps work in your organization. The DevSecOps model, a key to enhancing software security at all phases of the development lifecycle, includes four pillars: Discovery, validation, prioritization and remediation. These are vital for eliminating vulnerabilities from software products, in a way that does not overly tax development and security team resources or lead to higher costs, greater friction and reduced productivity.

In the previous article, we covered the release process and how to secure the parts and components of the process. The deploy and operate processes are where developers, IT, and security meet in a coordinated handoff for sending an application into production.