In the previous article about the coding process, we covered developers using secure coding practices and how to secure the central code repository that represents the single source of truth. After coding is complete, developers move to the build and test processes of the Continuous Integration (CI) phase. These processes use automation to compile code and test it for errors, vulnerabilities, license conformity, unexpected behavior, and of course bugs in the application.

Guest Blog by Daniel Parmenvik – CEO of bytesafe.dev For many, Software Bill of Materials (SBOMs) have changed from a manual list of assets for due diligence procedures to become an integral and automated part of software development. The ever increasing appetite for open-source software translates into a need to keep track of software assets (or open-source dependencies) for all applications, at any given point in time.

Today we make RKVST available for public use with a free access tier so you can discover what a Zero Trust Fabric can do for you. From tracking software supply chain lifecycles to nuclear waste, RKVST is a powerful tool that builds trust in multi-party processes, when it’s critical to have high assurance in data for confident decisions. But before going all the way you can start simple: tracking software releases and contents with SBOMs.

Not long ago, developers built applications with little awareness about security and compliance. Checking for vulnerabilities, misconfigurations and policy violations wasn’t their job. After creating a fully-functional application, they’d throw it over the proverbial fence, and a security team would evaluate it at some point – or maybe never. Those days are gone – due to three main shifts.

In application development, security plays an increasingly more prevalent role in protecting infrastructure and data, and ensuring a high level of user trust. Recently, Snykers Vandana Verma Sehgal and DeveloperSteve hosted a panel discussion with seasoned industry experts who shared their insights about exactly when security should be brought into app development.

In the first article in this series we covered the basics. In the second article about the planning process, we covered how developers incorporate security at the beginning of their project. This article explores DevSecOps during the Continuous Integration (CI) phase of the coding process and how to protect the code from supply chain attacks, license issues, and theft. Developers are advised during planning to use secure coding best-practices during the coding process.

For modern IT firms, developing secure software while meeting the market speed and scale needs has always been a paradox. Because of the fear of lagging behind in terms of speed to market, more than 52% of the businesses sacrifice security. That is why adopting DevSecOps and building security into software right from the start becomes an obvious solution. Sooner or later, this strategy is going to conquer the field of software development.

Since President Biden’s Executive Order last spring, the industry has been racing to define, standardise and now produce SBOMs to describe the hundreds of thousands of software products sold to and used by federal government and beyond. So far, little thought has been given to the management of SBOMs in practice. Finding the right SBOMs for all the software an organisation relies upon can already feel like hunting for needles in haystacks.