This is the third installment in a series about making DevSecOps work in your organization. We’ve looked at the first two pillars of the DevSecOps model—discovery and validation. In this post we examine the third—prioritization. Discovery enables security and development teams to identify software vulnerabilities, and validation allows them to determine which of these flaws present actual security risks and which do not.
The software development process is one with strict deadlines. The pace of innovation does not slow down. Because of this, developers often find themselves frustration as they try to ensure that the product they’re producing delivers on customer expectations, while also limiting vulnerabilities. The balancing act between product security and meeting the needs of a time crunch can lead to a product being rushed to the market, leaving it vulnerable to unpatched exploits.
The gap between Product Managers (PM) and R&D managers has existed since the beginning of the software industry. The PM wants to create the perfect product for their users, add shiny new features all the time, and support as many types of users as possible – while still maintaining a product that is well suited to them. PMs want to move fast. Devs, on the other hand, want to close tech debt, maintain a stable, secure, and robust system, and test every change extensively.
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.
Our lives revolve around measuring things on a daily basis. Comparisons between today and yesterday, between different resources – a bevy of factors. On average, a person makes about 35,000 decisions a day, and many of these require comparison tools to make the right decision. Technological advances today are faster than ever, and as a result, devices and other assets are rapidly improving.
Companies are increasingly turning to a Software Bill of Materials (SBOM) to provide them with information about what is in their individual software environment. SBOMs have already shown promising results. In a study from the Linux Foundation, over 44% of respondents said that a software bills of materials (SBOM) improves some aspects of their development processes.
*This is part of an ongoing series from Rezilion titled Enlightened Engineering: Reflections From Rezilion’s Tech Team By: Ofri Ouzan, Security Researcher, Rezilion
