- An OpenSSF blog post argues that results from security tools are claims made by someone else, and that your own action on them is a separate step.
- The post sorts software claims into seven layers in its Gemara model, and uses EU Cyber Resilience Act due diligence as its worked example.
- Teams can check that they hold an inventory, a written policy and records of action, not only scanner output.
A tool's verdict is someone else's claim
A scanner that passes an open source project has not made your decision. It has made a claim. In the framing of a new OpenSSF blog post, your own part of the due diligence is incomplete until your team acts on that claim.
The post comes from the OpenSSF, the Open Source Security Foundation. It is written by a single author and uses the EU's Cyber Resilience Act (CRA) as its example. The author says conversations around the CRA call for companies to record their due diligence activities and offer them as evidence of compliance. This is a practitioner's explanation, not a legal reading of the law.
Why the word 'attestation' confuses people
The post defines an attestation as a claim about something by someone. It is a statement from one party to another.
The author's example is proving who you are. You can say it out loud. You can show a photo ID. You can show an ID that the other person checks against a database. Each step carries more weight.
More proof is not always better. If the other person does not care, or already trusts you, the extra checking is wasted effort. The author says this is why software attestations can feel too technical. Detailed, high-fidelity claims are possible, but they are often not wanted or needed.
Seven layers, and who is speaking at each
OpenSSF's Gemara project sorts these claims into seven layers. The post says it also locks down definitions of overloaded terms such as "policy" and "control".
The first three layers hold definitions: guidance, controls and policies shaped by risk. The author says you rarely need a signature proving a standard such as ISO 27001 came from its publisher. You downloaded it from the source.
Layer four covers sensitive activities, such as a developer building a bank's mobile app. Signing software so users can detect tampering belongs here. Layer five covers evaluations, where a tool or person checks software against a defined target and reports whether it conforms. Layer seven is the audit. Someone collects all earlier claims and adds an opinion on whether the software should be used.
How the CRA example works in practice
The post walks through a manufacturer that consumes open source and wants to show it is safe. First, define what good means. For that list of objectives, the author points to the OSPS Baseline, a community-defined set of security objectives for open source projects. A catalogue tailored to the CRA is another option. Then write a policy that says what is acceptable for your risk profile.
Next comes an inventory. The post says you cannot audit what you cannot list. That list will likely be a software bill of materials (SBOM), a parts list for software. The author also suggests collecting SBOMs from your dependencies, including indirect ones. If your list and theirs match, the audit has more weight. Some SBOMs arrive with VEX statements, which say whether a known flaw affects that product.
Then you evaluate. In the author's expectation, automated checks would cover every item in the inventory. People would then look more closely at a smaller group where impact or risk is highest. Your policy should say which is which.
The author names three tools: OpenSSF Scorecard, Minder and Privateer. Scorecard ships with its own built-in control objectives. Minder and Privateer both support evaluation against the OSPS Baseline. Tools can disagree, so the post says your policy can name which tool is authoritative for which objective. It can also say how to settle conflicts, for example by taking the stricter result or sending the project to manual review.
The step that is easy to skip
The author warns that stopping at evaluation is a mistake. Tool output is testimony from a third party. Nothing has yet changed in your own pipeline.
The next step is your own action. In the post's words, your pipeline might refuse a component that breaks your rules, or lock it to a release that has the fix. The author also says teams may want to attest to the action they took, as a record that violations were fixed or that only compliant software was let through.
This shows where the risk sits. When a regulator or customer asks why a risky component shipped, a green scan is the tool's statement. Your records of what you decided are your own. The post says that when you are held accountable, you want to show your decisions were made well and from trusted sources.
Questions to put to your team
Ask whether you can list every open source component you ship, including indirect ones. Ask whether a written policy defines what is acceptable and which assets get manual review. Ask what happens when two tools disagree, and who decides.
Then ask for one example of a dependency your team blocked or pinned because of a scan, with the record to prove it. If no such record exists, you hold other people's claims. By this post's logic, the step of acting on them is still missing.
One caveat: the published post ends mid-sentence, just as it begins to describe this action step. This story reports only what the available text says.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: OpenSSF.
