TAG-Security Security Assessment (TSSA) Process

Goals

The TAG-Security Security Assessment Process (formerly the security review process) is designed to accelerate the adoption of cloud native technologies based on the below goals and assumptions:

1) Reduce risk across the ecosystem

The primary goal is to minimize the risk of malicious attacks and accidental privacy breaches. This process achieves this in two ways:

Improve detection and resolution of vulnerabilities through a clear communication process.
Enhance domain expertise in participating projects via collaborative assessments.

2) Accelerate adoption of cloud native technologies

Security assessments are essential but time-intensive processes that each company, organization, and project must perform to meet their unique commitments to users and stakeholders. In open source, finding security-related information can be overwhelmingly difficult and time-consuming. The CNCF TAG-Security Security Assessment Process, hereafter “TSSA” Process, aims to enhance the discovery of security information and streamline internal and external assessments in multiple ways:

Consistent documentation to reduce assessment time.
Baseline of security information to minimize Q&A.
A clear security profile rubric for organizations to align their risk profiles with the project’s and allocate resources effectively (for assessment and needed project contribution).
Structured metadata for navigation, grouping, and cross-linking.

This process is expected to raise awareness of how open source projects impact cloud native security; however, separate activities may be needed to achieve that purpose using materials generated by the TSSA, known as artifacts or the TSSA package.

Outcome

Each project’s TSSA package shall include a description of the project’s:

Security design goals.
Potential risks in design and configuration implementations.
Known limitations including expectations that certain security aspects are managed by upstream or downstream dependencies or complementary software.
Next steps to enhance the project’s security and/or its contributions to a more secure cloud native ecosystem.

Due to the nature and time frame of the analysis, the TSSA package is not meant to subsume the need for a professional security audit of the code. Implementation-specific vulnerabilities or improper deployment configurations are not in the scope of a TSSA. Instead, the TSSA aims to uncover design flaws, enhance the project’s security mindset, and clearly document its design goals and intended security properties.

Benefits of a TSSA

Undergoing the TSSA Process is a key step toward eliminating security risks and integrating security as a fundamental aspect of your system over time.

Key benefits of TSSA include:

Establishing a measurable security baseline.
Identifying and analyzing security issues and their risks.
Integrating a culture of security awareness among developers.
Documenting procedures for future compliance, audits, and internal assessments.

Components of the TSSA package

A complete TSSA package primarily consists of the following items:

Self-assessment : A written assessment by the project of the project’s current security status.
Joint-assessment : A hands-on assessment by both the security reviewers and the project team. It expands upon the self-assessment to offer a more comprehensive consideration of the project’s security health. This artifact, alongside the self-assessment, provides invaluable insight for both security auditors and end-users.
Joint README : Review the template used by the security reviewers to create a readme high-level summary at the end of the joint assessment. It is considered when performing due diligence.

Use of a completed TSSA package

A finalized TSSA package may assist the community in contextual project reviews, but it is not an endorsement or audit of the project’s security. It does not exempt individuals or organizations from conducting their own due diligence and complying with laws, regulations, and policies.

Draft assessments contain unconfirmed content and require peer review before being committed to the repository. Draft documents may also contain speculative content as the project lead or security reviewer is performing an assessment.
Draft assessments are only for the purpose of preparing final artifacts and are not to be used in any other capacity by the community.

Final presentation slides and the project’s joint assessment will be stored in the individual project’s folder with supporting documentation and artifacts from the TSSA. These folders can be found under assessments/projects by clicking on the project name.

Process

Creating the TSSA package is a collaborative process that benefits both the project and the community. The primary content is generated by the project lead and revised based on feedback from security reviewers and other members of the TAG.

If you are interested in a TSSA for your project and you are willing to volunteer as project lead or you are a TAG-Security member and want to recommend a project to assess, please file an issue

See the TSSA guide for more details. To understand how we prioritize TSSAs, see intake process .