Joel Krooswyk’s Post

View profile for Joel Krooswyk

Federal CTO @ GitLab | DevSecOps and AI

Last week, I mentioned that the US Army was going to require SBOMs for both COTS and contractor software. Here are the details you need - the timeline is short, and in my opinion this is a significant memo for anyone working with the Army! This memo is tied back to EO 14028, the NIST SSDF, OMB M-23-16, OMB M-22-18, and Army Directive 2024-02. These are the same publications I've found highly valuable the past few years. What's in scope? This memo applies to any computer software developed exclusively with Government funds to include any of the following: 1. Government-off-the-Shelf software 2. Computer software developed by a Contractor using exclusively Contractor funds or Independent Research and Development funds 3. Commercial computer software (as defined by FAR 2.101) 4. Noncommercial computer software developed and delivered to the Government by a Contractor Commercial computer software includes Commercially off-the-shelf (COTS) software and open source software. It does NOT include cloud services at this time. Contract language will now require vendors to: 1. Generate and deliver SBOMs 2. Include associated license rights According to Page 2, item b, PEOs/PM's will collect, store and manage SBOMs. Then, SBOMs will be monitored and used for vulnerability, incident management, and supply chain risk management. - this is a big one for dynamic management of SBOM, and I'm thrilled to see this verbiage. Key deliverables are only 90 days out! Within 90 days (Dec 2024): - Sample SBOM language for contracts will be in place - SBOM working group will be established - Subcontractors will be notified of SBOM language - SBOM management process will be codified - Risk and incident management processes will be codified for continuous monitoring of SBOMs Starting essentially January 1, 2025: - SBOMs will be collected and analyzed for all software in use - Risk and incident management activities will be executed The 6 page memo can be found here: https://lnkd.in/gkyRTZaq Sound difficult? GitLab can definitely help - don't hesitate to reach out. #sbom #dod #usarmy #gitlab

John Allison

Building compliant systems and processes | Serving the public good | Enabling innovation

6mo

And so it is finally happening. This has been in work for a long time, and I'm glad to see this finally coming to contracts. SBOM's are not perfect, and the DoD has a lot of work ahead of them to effectively use this deliverable. Industry has a lot of work to do to make SBOMs more accurate and easier to generate and manage. Once the DoD has this requirement firmly on contracts, you can expect large enterprises to include similar language for their large vendor contracts.

Like
Reply
Jason R... Weiss

𝗙𝗼𝗿𝗺𝗲𝗿 𝗗𝗢𝗗 𝗖𝗵𝗶𝗲𝗳 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗢𝗳𝗳𝗶𝗰𝗲𝗿. 𝗩𝗲𝘁𝗲𝗿𝗮𝗻. 𝗘𝗻𝘁𝗿𝗲𝗽𝗿𝗲𝗻𝗲𝘂𝗿. 𝗔𝘂𝘁𝗵𝗼𝗿.

6mo

Joel Krooswyk have you found any publicly accessible links to the Army SBOM Management and Implementation Guide cited in 6.e of the memo?

Like
Reply
Gerald Hirsch

DoD legacy mindset hacker 🏴☠️ (views and comments are my own and not a reflection of my employer)

6mo

And sadly, many DoD organizations have know idea what SBOM is much less that there is policy requiring it. 🙄 DoD needs to do better at spreading its message and goals. https://dodcio.defense.gov/Library/ Keep up the #CodeHustle🕺! #GovDev #TheRosieProject #VetsWhoCode 👩🏽💻👨🏿💻👩🏿💻👨💻👨🏽💻👨🏼💻👩🏾💻👩💻👨🏾💻👩🏼💻

Dr. Cory W.

Technical Director | Servant Leader | Cybersecurity, GRC, IT Project Management

6mo

That's pretty exciting! All programs of record (PoR) should follow the DODAF architecture which would include "as designed" system and service level diagrams/inventories of the assets being delivered. It's a step in the right direction to obligate this component level information (assuming there is repo and metadata structure in place to associate data and owner/location). The collective community of OSINT and Cyber defenders are often asked to respond to component level vulnerabilities across a global footprint of critical systems. API documentation for PoR's is also a wishlist item... I'll take a step further and suggest that Lockheed Martin's IDDL Framework would be the perfect framework to ingest the SBOM information and do "meaningful" threat modeling ahead of long range defensive mission planning. LH Threat Modeling PDF --> https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/LM-White-Paper-Threat-Driven-Approach.pdf #DISA #CYBERCOM #lockheedmartin #CIS #essentialdigitalhygiene

SBOM as a Service, the next big thing?

Like
Reply
Christopher Kuznicki

BSc. ISC2 x 10 | GIAC Advisory Board member | PMI x 3 | CompTIA x 11 | GSEC | LPI Linux Essentials | ITIL v4 | CCNA | Microsoft x 10

6mo

Wonder if this will translate over to the other components…

Like
Reply
See more comments

To view or add a comment, sign in

Explore topics