Ep. 163 Beyond the SBOM for Secure Software Development

Want to leverage you next podcast appearance? https://content.leadquizzes.com/lp/fk1JL_FgeQ

Connect to John Gilroy on LinkedIn   https://www.linkedin.com/in/john-gilroy/

Want to listen to other episodes? www.Federaltechpodcast.com

Everyone likes to hit the “Easy” button, especially software developers. Rather than laboriously generate code line-by-line, today’s software professionals may just grab code from a repository and re-purpose it. Why reinvent the wheel?

Malicious actors have noticed this process and have inserted code into many libraries, acting like a like Trojan Horse. As a result, some organizations are offering codes that have been inspected. They look at known vulnerability lists and see if the code includes any of them. If not, it is given a seal of approval.

Frequently, this is called a “Software Bill of Materials.” A convenient solution: however, upon inspection, SBOMs can be problematic.

The weakness of SBOM

During today’s interview, Joel Krooswik, Federal CTO for Gitlab, described in detail some of the ways software must be continuously protected.

According to the SBOM folks, the code is clean when leaves the “shelf.” However, due to continuous improvement code changes hourly. All an SBOM provides is a certification at a specific point in time for known vulnerabilities.

Joel Krooswik gives listeners an enterprise architect’s perspective. He indicates that digital transition introduces new code, new architectures, and innovative approaches. At any step along the way, security can be compromised.

The unknown unknown

Donald Rumsfeld famously said, “There are unknown unknowns.”  This can be directly applied to what GitLab calls “fuzz” testing. This allows professionals to throw random inputs into a system to see what happens. Finally, you get a view of a potential possibilities that are not obvious.  

Joel Krooswik presents many insights when it comes to protecting software. He states that just because a system is identified as needing a patch, it does not mean it will be done in a flash.

Understanding all the risk factors will allow a federal leader to make a prudent choice when it comes to protecting software systems.

.