By Eddie Knight
Introduction
There are several places in security and compliance where we have semantic overload that causes undue complexity. One case that comes to mind up front is the word “policy,” which can describe the ruleset configuration for a security tool, or it could describe the rules that an organization sets for itself. Another overloaded term is “control,” which could be a statement or a set of information describing a security objective, or it could be a process that was implemented to achieve an objective.
Beyond the semantic overload that makes it unnecessarily difficult to work in the security and compliance space, we also have terms that have clear definitions. These terms, however, can have a wide variety of possible implementations. So while we’re not experiencing semantic overload, we are running into functional overload. That’s the type of scenario that we’re dealing with when we look at attestations.
It can sometimes feel like people are crossing wires when they talk about attestations, because sometimes it’s one thing and sometimes it’s another thing, and we might find ourselves wishing that people would just decide what they mean when they say attestation… But really, this isn’t an undue complexity. This is a natural complexity that arises from the massive breadth of the ecosystem we’re trying to secure.
The OpenSSF’s Gemara project seeks to address both of these complexities. The undue complexity of overloaded terms, Gemara tackles by locking down definitions and taking an opinionated stance. Gemara can also help us with the natural complexity by helping us understand the space in which each thing operates. So when we have something like an attestation that belongs in a variety of places, we can shift from asking “What is an attestation?” to “What is an attestation in this particular circumstance?”
Level Set
Now that I’ve used four paragraphs in a long introduction, it would serve us to rewind just a bit and establish a conversational baseline.
Attestations have always been an important part of life, even before we had a word for them. An attestation is a claim about something by someone. It’s a statement that is made by one party to another. It’s a fairly simple concept.
What comes downstream from it is the complexity. When do we need to make claims, and how?
I often need to make a claim about who I am. So I can do it verbally. I can also do it by showing identification. These are both attestations: I’m attesting to who I am. When I do it verbally, it carries less legal weight than if I do it with a photo ID. But that carries even less weight than if I do it with a photo ID that you can validate against some database of sorts. So as technology grows and enters into a particular space, our attestations can become more verifiable, more robust.
I might also attest to my relationship status. When I tell you that I’m married, that is an attestation. When I show you a marriage certificate, that is an attestation. When you look up that marriage certificate in a database and find that it was properly filed and was signed with witnesses, that attestation carries significantly more evidence along with it, and you’re going to treat that attestation much differently if this claim is important to you. But on the flip side, that claim may be trivial to you, so those validations aren’t something that you need to pursue. And a more complex attestation becomes unnecessary weight.
It’s not creating any value for you because you didn’t need to have all of these verifications. It may be that you have already done the verification yourself. It may be that you have already established a line of trust with me to where you don’t need to validate my word, or it may be that you just don’t actually care whether or not I’m married.
And this is where our digital attestations for software and security and supply chain decisions can become very, very complex. We are able to introduce extremely detailed, high-fidelity claims, but oftentimes those claims are not wanted or needed, or the verification tools require some learning for us to understand and operate. And this is why the conversation around attestations can sometimes feel way too technical and too complex.
Applying the Gemara Lens
When we look at this through the Gemara lens, we can start stratifying the different types of attestations. And in doing so, we can distinguish who they’re created by, who they’re created for, and when they should be used. Following the logical model provided by Gemara, we have seven total layers, and the top four are all typically where the conversations about attestations happen. Although attestations, like I said earlier, are so intrinsic to life that they belong everywhere in all seven layers of the Gemara model.
The first three layers are the definition layers. You could provide an attestation saying that these definitions were, in fact, created by the people who said they created them. But you probably don’t care that much. You just want the artifact so you can reference it.
You don’t often need to have a signature from the International Organization for Standardization saying that this document is ISO 27001. You know what it is because you went to their website, you got it, you pulled it down. There’s no reason you need to do a robust verification to make sure that it comes from the source it claims to represent. So we can largely overlook attestations in these first three layers simply because we have diminishing returns on the value.
But as we go up higher in the Gemara layers, we build upon those definitions which are defining the things that need to be done, the things that need to be checked, and we start getting into actually doing work. In fact, the fourth layer of Gemara describes sensitive activities.
These sensitive activities can be anything from a teller operating a bank counter to a software developer writing the mobile app for the bank. Any number of activities. But all of those activities could make attestations while they’re working.
And this is where we see a lot of the conversation around digital attestations: When software is produced, it can be signed so that a user who is pulling down that software from the internet can confirm that there is no tampering done and that this is truly the piece of software that they are intending to run from the person that they trust to create it.
Now, there’s another category of attestations that may accompany a release of a piece of software, but the Gemara model would categorize it slightly differently. These are claims about the state of the software. These are done from an evaluation. That evaluation will follow some defined target state. It’ll have an objective of some kind or a policy that it needs to follow, and it will either manually or automatically perform a series of checks to evaluate this piece of software and then make a claim about the conformance state of the software based on those defined objectives.
Then, in some cases, we may also want to provide some sort of evidence that we took action based on those findings. This would be the record that we have successfully remediated certain violations. And we want to issue a claim stating and attesting that we did properly enforce any of those violations, or we did properly allow through only things that met the objectives.
Addressing Regulation with Gemara
And this brings us closer to the topic of due diligence.
Conversations that we’re having in light of the EU’s Cyber Resilience Act (CRA) say we need to record our due diligence activities and provide those as evidence for our compliance with those laws. This is what Gemara describes as an “audit” activity.
Audit is the highest layer, layer seven, where someone compiles all of the previous claims that have been made about the state of the software. Then they can attach their own opinion to it, saying, “I believe that this should or should not be used, with or without modifications and precautions.”
There are a variety of different tools that fall into the different categories we’ve just described. But now that we’ve established that everything is producing an attestation of some kind, and we’ve established that they are all categorically sortable, we can start to look at which attestations are actually useful for our specific purposes.
In the case of the CRA’s due diligence requirements, it’s very likely that you will want to use as many attestations as you can, because these are the signals that you are using, and you are saying that you trust these signals to inform your decision making.
So that way, when you are held accountable for your decisions, you can show that you made these decisions well and thoroughly, and that the information you are using was coming from trusted sources.
This is especially critical when you’re responsible for due diligence of hundreds or thousands of pieces of software that each have hundreds or thousands of transitive dependencies. It is essential that you are able to properly integrate the best tools at the appropriate times to create the value your scenario calls for.
To bring this conversation to a close with an example, we’ll look at the open source consumption requirements provided by the CRA. When consuming open source, a manufacturer wants to demonstrate that they are consuming safe open source that follows the necessary best practices.
Using the Definition Layers
Immediately, when faced with this due diligence requirement, the practitioner is forced to have a definition of good. This comes from a combination of guidance, which is Gemara’s layer one, controls, which is Gemara’s layer two, and policies informed by risk, which is Gemara’s layer three.
The control catalog in this example could be the Open Source Project Security Baseline (OSPS Baseline) or another emerging control catalog that is custom tailored for the CRA, which defines the objectives that your projects must follow for you to consume them.
Then you would want to have a policy that states what is acceptable based on your risk profile. You need to be able to demonstrate that you have properly understood your risk profile and you’ve properly created rules within your organization to pursue these specific objectives.
Everyday operations at Layer 4: Sensitive Activities
Then at Gemara’s layer four, you will need to have some sort of continuous integration process that will inform you of what software you are consuming. In order to do a proper audit, you have to have a proper inventory. This is likely going to come in the form of an SBOM.
Still within the context of layer four, you may want to gather SBOMs that are produced by your dependencies, including transitive dependencies, to ensure that your view of your dependency tree matches what your projects that you’re consuming declare is their dependency tree. This will increase the fidelity of your audit because you can show that from multiple perspectives, all of the data matches. If you are a bit lucky, you may also find VEX statements coming alongside those SBOMs, which you can use to help customize the evaluations that you are going to be performing as part of your due diligence.
Gathering information at Layer 5: Evaluations
But now that you have your inventory of all of your targets that you need to be doing due diligence on, you’re very unlikely to be doing manual due diligence for all of them. This is where your policy is going to be critical. You need to have a policy internally that clarifies what requires a manual evaluation and what requires an automated evaluation.
In most cases, you’ll do an automated evaluation for everything, and then a core set of high impact or high risk assets will need that manual follow-up to close certain loops that may need closer review.
Once you’ve gathered the attestations regarding your software inventory, this is your recipe for doing the actual evaluations that will form the core of your due diligence audit result. There are several tools that can come in handy here, depending on your policy, your approach, the fidelity that you need, and probably other variables that your particular organization has.
In most cases, the OpenSSF Scorecard is the most robust tool to operate your evaluations because it has a long history with deep expertise informing each of its evaluations. However, it should be noted that Scorecard ships with its own baked-in control objectives.
Other tools can be brought in to supplement these Scorecard results in a flexible way to fit with community-defined definitions or even custom definitions that you’ve provided yourself. Two examples here are Minder and Privateer, which both provide integrations to support the evaluation of open source projects against the community-defined OSPS Baseline objectives.
Running several evaluators side by side raises a new question: what do you do when their results don’t line up? Scorecard, Minder, and Privateer each follow different paths to evaluate an open source project’s security hygiene, and one tool may pass a project on a check that another tool fails. This is where your layer three policy can act as a filter. Beyond saying which objectives matter, the policy can optionally state which tool is authoritative for which objective, how results from different tools map back to a common set of control objectives, and how to deconflict disagreements, such as deferring to the stricter result or routing the project to manual review.
But you’d be making a mistake if you stopped there, because you’ll note that we’ve only reached Gemara layer five. These attestations provided by open source tools are only that. They are claims made by someone who is not you, and you have not yet acted on those.
Decision-making at Layer 6: Enforcement
The next thing in your due diligence process is very likely to demonstrate that you have acted on those evaluation results as the consumer of that software. You perform some sort of remediation or block in your own pipeline, such as rejecting a dependency that fails your policy or pinning to a patched version, to prevent malicious or vulnerable software in your dependencies from reaching your end users. This is Gemara’s layer six, which the OpenSSF’s Ampel or Darnit projects can help you implement.
Now, once you have responded to the result of your evaluation, you have likely made an attestation stating that you performed those enforcement activities. That means that you have, at minimum, attestations in your hand from the CI and software development processes, from your evaluators that make certain claims about the software that you are using and producing, and you also have attestations about what you did with all of that information in your software development life cycle.
Bringing it together with Layer 7: Audit
But this is not your due diligence attestation. And this is where Gemara’s layer seven comes in to help you tie everything together.
And in fact, I would highly recommend you use the schema for this if you are subject to the CRA, so that way you can have a more structured pattern for demonstrating that you have performed your due diligence. You can programmatically roll up all of your previous attestations that you have gathered and link to those documents by identifier in an audit log. Then a human can open up that audit log and document an opinion, simply saying, “I’ve reviewed all of this evidence and I recommend that this software is safe to use.” You have done your due diligence because you have reviewed all of the previous attestations.
You are in this moment claiming, “I believe that this is the correct inventory of our software. I believe that we have properly executed evaluations across that entire inventory. I believe that we’ve made the correct responses to any violations that existed, and I believe that all of this is in accordance with a solid industry best practice.”
You’re rolling up that layer four, layer five, and layer six attestation set in light of your layer two or layer three objectives and policies, and you’re signing that off in a final due diligence claim. There are less stringent ways to do due diligence, but I would argue that those simpler methods of doing due diligence may not actually be easier in the end.
The OpenSSF ecosystem is full of extremely productive operators providing high-impact solutions for each of these slices. And through the Gemara project, you’re able to streamline and automate all of these different tools together.
And all you need to do is connect them together and do one final pass to make that final attestation of your own.
About the Author
Eddie Knight is a Software and Cloud Engineer with a background in banking technology. When he isn’t playing with his 3-year-old son, he combines his passion and job duties by working to improve the security of the open source software ecosystem. Eddie helps lead the FINOS Technical Oversight Committee and the OpenSSF ORBIT Working Group.