Recommended term for a company's interpretation of SLSA?

[MarkLodato]

A company that does SLSA will likely have more requirements than are strictly defined in the SLSA specification. For example, they might have requirements about two-party review (not in SLSA v1.0), or that only a set of builders are considered SLSA Build L3, or that some additional sign-off is required. They will need a term for this. It will be too annoying to say "SLSA + x + y + z".

Should SLSA have a recommendation for how to brand it? In particular, we probably want to recommend against a company using a bare "SLSA" to mean "SLSA + our requirements".

/cc @TomHennen

[joshuagl]

Yes, I think SLSA should recommend against using a bare SLSA when they have added their own requirements.

Would the simplest thing be to encourage companies to group their requirements as a track and refer to them the same way we would any other track? SLSA Build L3 + SLSA Source L2 + FooCorp SSDF L2

In simpler parlance, companies might say something like: SLSA + FooCorp SSDF

[TomHennen]

I think there might be a couple of different things at play here.

1. A company's interpretation of SLSA specifically (e.g. we want a little extra from our builders so we don't trust just anyone)
2. Extra things that company does in their supply chain (e.g. SSDF, required 2 party review, etc...)

I think #2 can be easily handled just as additional levels in the repeated verifiedLevels field from #734. For #1 however I wonder if we could suggest folks prefix it E.g. Acme SLSA or SLSA(Acme). We'd need to define what orgs can do with that framing. E.g. we probably don't want them going too far afield from what SLSA already defines, but just indicate their interpretation or narrowing of the requirements?

[mlieberman85]

I can tell you how it worked at the various banks and large enterprises I've worked at. Banks had policies which informed controls, standards, processes, and procedures. It was always expressed as something like:

ACME'S Software Ingestion Standard requires packages to be SLSA 3, use FIPS-180 compliant hashing, ...

I don't remember any of those groups publicly branding and expressing their requirements. It was usually just things that were discussed with potential vendors. I never really saw it expressed as the way you have above. Do we want to recommend making it clear that something like a company's standards should be thought of including SLSA instead of it being a company standard + SLSA?

[TomHennen]

I don't remember any of those groups publicly branding and expressing their requirements.

I think this has private internal uses as well. A company might want to set a policy that says "All builds must be SLSA L3 but using our opinions and integrated with our infrastructure". It would be convenient to have a succinct way to express that.

A failure mode of not having a way to express that is that engineers at a company hear "all our builds need to be SLSA L3", they see Product Foo is SLSA L3 and start using it, but 1) Foo isn't trusted by the company, and 2) No one has integrated Foo with the company's monitoring and policy systems.

[mlieberman85]

I see. The only way I've seen this expressed in a reasonable way is by establishing a standard or procedure that cites SLSA in it. I've never seen it expressed succinctly. I've always seen it expressed as something like:

ACME's software authorization standard:

All software MUST comply with:
- SLSA 3 Build
- Have SBOM
- Encryption follows FIPS ...

First party software MUST also comply with:
- Approval procedures from System Owner
- Follow ACME's "writing secure code" guide

Third party software MUST also comply with:
- Being in trusted list of approved vendors
- Run SCA scan
- Have no critical CVEs at time of ingestion

The above is oversimplified, with a lot of these documents being needlessly long. Granted the above is what I've seen expressed at larger enterprises with lots of staff to support generating these policies, standards, etc.