Document: draft-ietf-scitt-architecture Title: An Architecture for Trustworthy and Transparent Digital Supply Chains Reviewer: Jason Livingood Review result: Ready with Nits This is an interesting proposal and very worth proceeding with in the IETF. There is a question about its practicality, but that will only become clear in future Internet-Drafts that build on this architecture. The architecture attempts to create a broader SBoM of sorts that covers the entire supply chain of software generation (much like what SDL tries to do, but for packaged released software). SCITT is something of a mix between a Cyber TrustMark and an SBoM. It does mention crypto agility considerations in its own architecture which is nice.ÊThis document also makes a very good case for why software producers (not users) should be held to higher security standards. This document proposes a data structure (SCITT) for software supply chain (not limited to OSS). This is for the entire pipeline, not just SBoMs, which apply only to packages or third-party dependencies. It shows a gap in what SBoMs can cover, by putting together an architecture to make sure specific security measures implemented at every stage (from code to deployment) is verifiable in a unified schema. Furthermore, every security measure at every stage of the supply chain is signed with proof.Ê I really like the idea of having a unified ÒlabelÓ of sorts that can account for all facets of software supply chain. It also accounts for Òadd-on servicesÓ depending on the software and the use case. However, it has the same problems as having an IoT label, like information overload, inaccurate data, and lack of interest in implementation without a push from a regulator. Nit: I am not sure which fields are deemed required versus voluntary. Minor Observation: The document assumes that the software producer has enough resources to immediately fix a vulnerability so that it does not show up on the transparency chain. Most small scale software providers will likely not change anything in their process due to the transparency from SCITT due to other release considerations.Ê Minor Observation / Possible Nit: What are the security measures to mitigate security vulnerabilities in the SCITT schema itself? Beyond saying that sensitive information should be hashed locally before sending to the transparency service, there are no additional security considerations (the document mentions these are out of scope though and should follow standard security practices recommended by IETF). The only privacy consideration is that SCITT issuers must check that providers donÕt have PII (which historically doesnÕt work in practice well). If I was an attacker, I can go ahead and modify the output of this schema to include false provenance and security statements. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
