in-toto Joint Security Assessment
Completed: May 2019
Security reviewers: Sarah Allen, Justin Cormack, Brandon Lum
Project security lead: Santiago Torres Arias
- Source code: github.com/in-toto
- Web site: https://in-toto.github.io/
Background
Supply chain compromises are a powerful attack vector. In cloud native deployments, if you control the supply chain you can potentially reconfigure anything in an insecure way, since everything is software-defined.
In-toto ensures the integrity of the supply chain itself, specifically:
- What steps are to be carried in the supply chain
- Who can carry out each step
- How the artifacts between each step interconnect with each other
Maturity
- 1 public company case study: Datadog Agent full pipeline
- Multiple integrations: Debian apt get ( 3 Debian contributors ), Jenkins plug-in ( +1 contributor ), K8s admission controller ( +1 contributor )
Summary
Design: straight-forward, adaptable to variations in supply chain pipeline and process. Non-prescriptive approach leaves opportunity for additional higher-level tooling.
Analysis: focused approach to mitigating risks in supply chain which are underserved by other tech. Threats are well-understood and mitigated, including a reasonable degradation approach. Solid code processes; resiliency would benefit from additional participants.
All questions from reviewers were addressed in self-assessment with non-critical issues captured as issues and noted below.
Recommendations
To address supply chain vulnerabilities, companies need more than technology, they will need to adopt or formalize effective policies and procedures.
CNCF recommendations
- Identify UX Researcher to engage 2-3 companies or projects to evaluate the time and effort required to integrate in-toto and recommend improvements
- TAG-Security collaboration to document common supply chain threats and complementary solutions that would cover security of all inputs (see issues#224 )
Project recommendations
- Verify in-toto’s supply chain with in-toto in-toto/issue#278
- Improve introductory documentation to clearly communicate security scope docs/issue#15
- Additional integrations, examples and/or documented case studies (such as: in-toto/issue#284 , roadmap#3 )
- Consider encoding best practices in default implementation (such as issue#287 )
- Proceed with
CII silver
badge
&
roadmap
.
Just a few open items, listed below:
- Projects MUST monitor or periodically check their external dependencies (including convenience copies) to detect known vulnerabilities, and fix exploitable vulnerabilities or verify them as unexploitable.
- The project MUST implement secure design principles, where applicable.
- The project MUST provide an assurance case that justifies why its security requirements are met. The assurance case MUST include: a description of the threat model, clear identification of trust boundaries, an argument that secure design principles have been applied, and an argument that common implementation security weaknesses have been countered. (This assessment should be able to provide reference, if needed.)
Additional recommendations
- Formal security audit: no blocking issues for a formal code audit
- Additional organizations contributing to as core members of the development team, recommend addressing documentation issues above in advance of CNCF promotion
- Consider integrations with other CI/CD projects
Tracking issue: https://github.com/cncf/tag-security/issues/166