Years ago, people would laboriously code character by character. This tedious process would take hours and would include errors. Over the years, libraries of prewritten code have evolved that allow software developers to “grab” some code, modify it, and finish a project earlier.

Malicious actors have taken advantage of this short cut and have injected code into these software libraries that get taken along for the ride.

One proposed solution is something borrowed from the shipping industry. A commercial invoice may be packaged with a bill of lading to indicate the contents of the package. This “assurance” has been transferred to the world of pre-written code and is now called a “Software Bill of Materials,” or SBOM.

In a world where you are shipping a ton of Portland Type II cement overseas, this bill of lading works finds; it has some challenges being transferred to the dynamic world of software.

In a typical federal environment, there is continuous change in the code itself. It would be difficult to change on ton of a manufactured product like Portland Type II Cement. However, the once approved software package may have so many changes that the Software Bill of Materials may not have any validity.

During the interview today, David Jurkiewicz unpacks the concept of an initial SBOM and then how software packages can evolve over time and still retain compliance. His company can take this basic guarantee and examine the software for many concerns, including.

·       Vulnerabilities

·       Dependencies

·       Integrity

·       Malware

·       Foreign presence

·       License

David Jurkiewicz provides details on how companies can resolve vulnerabilities and ensure safe operations in a world where code is grabbed off the shelf and slipped into a package.

 

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