DevSecOps is a key component in companies’ efforts to build strong security into the software products they create. The methodology brings together security and development teams in a joint mission to deliver high-quality, reliable and secure software.

Log4j continues to be a thorn in the side of security leaders, who have spent the last several months battling the recently discovered flaw in Apache’s Log4j software. In a recent webinar, Yotam Perkal, director of vulnerability research at Rezilion, said the implications of the bug are far-reaching and will likely be exploited for years to come. Apache Log4j is an open source Java logging library used in millions of Java applications worldwide.

The new serious Linux Kernel vulnerability dubbed ‘Dirty Pipe’, due to its similarity to the 2016 high severity and easy to exploit DirtyCow vulnerability, was originally disclosed on March 7th by Max Kellermann. Kellermann found the bug accidently while researching corrupted log files on a log server.

Software Bill of Materials or SBOMs are gaining momentum because they really do make a difference when it comes to enhancing the security and reliability of software. Here are three reasons why organizations need to jump on the SBOM train now.

A Software Bill of Materials (SBOM) is a list of ingredients that make up software components. This includes code updates, vulnerability patches, new features, and any other modifications. An SBOM is useful in tracking the history of software products and their components. But SBOMs are static, and frequently changes need to be made, which can be labor intensive and costly for organizations.

The recent invasion of Russian troops into Ukraine territory was preceded by a blitz of cyberattacks targeting banking systems, government websites, and critical infrastructure. The cyberattacks started long before Russian troops began to descend on Ukraine borders. Cyberattacks date back to 2015 when the Russian intelligence organization, the GRU, targeted Ukraine’s industrial control systems networks with malware.

The Software Bill of Materials (SBOM) has moved from relative obscurity to mainstream seemingly overnight, although the concept has been around for a while. As organizations look to ensure that the software they are producing, buying, and using is secure and reliable, the SBOM has become a valuable tool.

Attack Surface Management (ASM) is the ongoing discovery, inventory, classification, prioritization, and security monitoring of an organization’s IT infrastructure. The attack surface is all of the entry points where an unauthorized user or attacker can pull data from.

A Software Bill of Materials (SBOM) can be a powerful component of software security, and that’s why the rise of SBOMs should be good news for product security leaders and their teams. Because these documents are formal records that contain the details and supply chain relationships of the various components used in building software, they provide extensive histories of the software that can help organizations identify potentially risky components or sources.

In previous posts, we’ve discussed how the Software Bill of Materials (SBOM) concept will make a difference in cybersecurity, and why context is needed to generate the most value from these formal records of the details and supply chain relationships of software components. As helpful as SBOMs are in tracking the history of software products and their components, most of these documents remain static. That’s not ideal for a scenario in which there is near constant change.