On December 22, 2016 Cybersecurity firm CrowdStrike published an interesting blog “Danger Close: Fancy Bear Tracking of Ukrainian Field Artillery Units” talking about the compromise of an application written by a Ukrainian military officer that reduced the time to fire D-30 122mm towed howitzers, from minutes to 15 seconds. Clearly a huge advantage in the middle of a war.
An Android app with the same name, and some Russian code inserted, surfaced soon after and was also used by the Ukrainian military. As per the blog, this inserted code in the application enabled Russian troops in the Crimea war to detect the location of Ukrainian D-30s. In subsequent conflict, 80% of the Ukrainian D-30s were destroyed resulting in a software supply chain attack with lethal consequences for Ukraine.
A supply chain lesson was learnt: Knowing what’s in your software is interesting but knowing what is unknown in the software you ship, and use, is critical. Cyber-security tools fail to identify the ‘Known Unknowns’ and take your focus ONLY to the ‘Known Knowns.’ Supply Chains can be poisoned!
You would be right to wonder about the lax cyber-security of the Ukrainian defense establishment. Shouldn’t they be more careful? The fact is that they are very careful and to-date, use the best cyber-security tools. So, what went wrong? The fact is that the technology to unearth all the components within an application — with all its dependencies- didn’t really exist back then. This, lack of insight, provided an opportunity for their adversaries to infiltrate their operations.
Today, in your organization, even with app-sec tools, software composition analysis and shift-left security tools and runtime security controls you too cannot detect a supply chain tamper. That’s where more than 70% of your code comes from and where your biggest security risk ultimately comes from, leaving the software you ship or use susceptible to tampering. That’s why we created Lineaje!
Read more about our company here .
Fast forward to May 12, 2021. The Biden Whitehouse published its Executive Order on Improving the Nation’s Cybersecurity (Executive order 14028) to “Enhance Software Supply Chain Security”.” A key part of this mandate is for companies to Attest to two things:
What is in your software?
What part of your software is ‘unknown’ to you?
It also requires that procuring organizations now Assess the risk in using your software! For most of us who have built software used by millions, no one has ever truly Assessed your software. Now they will.
Following this Executive Order, NIST provided its guidance (SP800–218) a year later. It modified the SDLC and gave specific guidance on how software providers must attest the software they sell. The Office of Management and Budget (OMB), on September 14, 2022 , stepped in to require federal agency conformance to this guidance (M-22–18). Make sure you review the deadlines that vendors need to pay attention to carefully:
A recent memo (MV-23–02) issued by the US General Services Administration (GSA) on January 111th, 2023 states that it will start collecting attestation letters for all impacted software, regardless of whether it is considered critical, on June 12th 2023. That is a full quarter earlier than the previously established date of September 14th, 2023.
Net, you should be prepared by June 12 with your self-attestation letters and associated artifacts if you want to sell to these agencies.
Additionally, artifacts like SBOMs, output from tools that validate integrity of the source code, checks for potential vulnerabilities etc. can be requested depending on the procurement agency. You need a tool that collects these for all the software you sell in any form.
Ticking TimeSBOMs! Do You Know the Lineaje of your software?
EO14028 is complicated. Hundreds of pages of follow-up documentation will make your eyes glaze over. However, at the core of it there are two simple requirements. For achievers, we have one recommendation:
Requirement: A Self-Attestation Letter
You should sign it with confidence if you know the answers to these two questions:
Q1: Do You know the which components that make up your software and can you attest to their integrity?
You need the Lineaje of all software you deploy or ship, to attest the known unknowns?. If you use third party components that were not built in your CI/CD, can you attest to their integrity ?
Q2: Do you know what components in your software are not known?
That’s a tough one, isn’t it? This is the D-30 Howitzer question. Tell us about the components that you are not 100% confident of the source. Lineaje analysis has shown that about 20–30% of all COTS software is unknown today. Your current tools, including SCA tools, have no attestation basis. And if you have high OSS dependencies, that percentage is higher. And that is why Lineaje’s SBOM360 makes an explicit list of un-attestable known knowns in your software- so you can resolve them BEFORE you attest.
Requirement 2: A Published SBOM
You will need to publish a compliant SBOM. The SBOM you need to publish must be just right! And One size doesn’t fit all. That means:
The right format: Standard Digital format like SPDX. .
The right information: Expect to ship multiple versions of your SBOM to comply with requests that are misaligned. Expect that civilian agencies need much less information than if you sell to the defense or military for example. Your customers in high regulation verticals will have their own demands.
The right updates: When your software changes, so should its SBOM. In fact, software upgrades on previously purchased and currently deployed existing purchased software now requires SBOMSs. So, if you sold your software before the deadlines and now have a new version, that version cannot be taken unless you update your SBOM. If your update your SaaS software daily, update your SBOM daily too! You need continuous SBOM creation and delivery!
Recommendation: Assess each SBOM BEFORE you publish it? Will your SBOM showcase your weaknesses or strengths?
Recommendation 1: SBOM Assessment
EO14028 requires procuring organizations to Assess the SBOMs of all software they buy.
While your sales organization may be on the frontlines, addressing concerns shared by customers, the responsibility for addressing assessment findings in a timely manner falls squarely on your product team and CISO organizations. This is where Lineaje SBOM360 helps, by being the industry’s first SBOM assessment tool to proactively manage and monitor your SBOMs, no matter how they are created.
With SBOM360, you can not only know what’s in your software but also know “how good is it” in terms of code quality, provenance, maintainability, security posture, vulnerabilities and so on and so forth. Not only that, but you can also compare across versions to show that your software is getting better with age!
If you’re a software vendor, and this post has resulted in sudden heartburn and anxiety, put away that bottle of Pepto, and reach out to us today.