With security attempting to close the gap between development and testing in terms of testing frequency, tools are becoming more standardized for each development organization. There are numerous tools available, some of which are free and open source, while others are commercial, off-the-shelf products that are all attempting to compete in some way. This also means that customers and procurement organizations face a bit of a struggle to find a tool that meets their needs, which is why there is a lot of emphasis on implementing open source solutions, as they are a good starting point for many and have de-facto become the standard internally. This has both a beneficial and detrimental effect.
The advantage of this is that you will quickly have a tool at your disposal for performing the necessary security checks. However, the disadvantage is that security rules are frequently out of date or are maintained by a small number of individuals, putting you at risk of missing out on the latest security threats on the market.
Regardless of the tools chosen, one fundamental requirement that will be prevalent in 2021 is that the tool of choice must be able to integrate with your CI/CD pipeline, automate security testing, and provide feedback on critical and high severity vulnerabilities, such that the pipeline build will prevent the deployment to production if security requirements are not met. This is critical in 2021, as you want to automate as much of the CI/CD chain as possible.
Generally, any COTS vendor will endorse this approach and provide constructive feedback to the development teams. It is critical that developers receive notification of a security issue and immediately begin resolving it, as this is the only way to improve the overall quality of the software deployed. The goal here is to automate as much as possible from the DevOps perspective, while also adding security to the equation.
However, even if much of the security assessment process is automated, there is still a need for auditing the results of an automated scan. A security auditor is responsible for a variety of tasks, including flagging an issue as relevant and a genuine defect, while other issues discovered may be flagged as irrelevant or even a false positive. And it is within this complexity that much of the complexity associated with security testing and verification exists; even if the process of performing security tests is automated, manual work on identified issues must still be performed. And that requires both time and expertise.
To verify these issues as a security auditor, you must be skilled, quick, and add value to the project. When we consider the fact that the number of developers far outnumbers the number of security auditors, we see that this equation is doomed to remain unresolved.