Problem: Today, open source projects do not have a consistent mechanism to publish compliance and regulatory details about what the project does in a machine readable format and to enable assessment activities to occur in an automated manner. Adopters do not have a way to understand what capabilities and controls projects have in place and what their responsibilities as consumers are as defined by the leveraged project.
Adopters today have to manually review a given software project, understand based on existing documentation if it can meet a compliance or regulatory requirement, and then determine if it does it already or if it's configurable by the adopter. They have to do this with every release. If 1 project decides to express this in one manner, another may choose a very different one and the adopter now has two ways in which they can’t reason about the compliance properties of both projects. We need a specification and guidance to allow projects to consistently and uniformly express their compliance capabilities and posture for adopters to act on.
Other areas:
Project to project dependencies for compliance requirements
Consumption of compliance metadata/information
Standardization on language for expression (OSCAL recommended)
Has the needed evidence and the reporting for what auditors need alongside evidence
Tie in with policy engines in a consistent way to avoid vendor lock-in
Impact:
Depending on the shape and nature of this project, the desired experience by adopters of cloud native projects is that when they deploy a given project the project contains sufficient metadata that in combination with a policy engine allows for decisions on whether a piece of software is permitted to be deployed in the target environment.
Such metadata shows how the project can achieve compliance (with configurations) and how it HAS achieved compliance (based on its design and operation in a given deployment environment). The evidence can also be turned over to auditors in an automated fashion to enable reasoning about system properties and conformance with regulatory requirements on a continual and ongoing basis driven by deployment frequency thereby reducing the manual audit (internal and external) activities performed by covering the technical control elements (roughly 30% of a given framework like NIST))
A lot of organizations just use hundreds of spreadsheets with 1 compliance engineer to automate. Spot checking is not good enough here.
Scope: How much effort will this take? ok to provide a range of options if or
"not yet determined" for initial proposals. Feel free to include proposed tasks
below or link a Google doc
Intent to lead:
[ ] I volunteer to be a project lead on this proposal if the community is
interested in pursing this work. This statement of intent does not preclude
others from co-leading or becoming lead in my stead.
Proposal to Project:
[ ] Added to the planned meeting template for mm dd
[ ] Raised in a Security TAG meeting to determine interest - mm dd
[ ] Collaborators comment on issue for determine interest and nominate project
lead
[ ] Scope determined via meeting mm dd and/or shared document add link
with call for participation in #tag-security slack channel thread add link
and mailing list email add link
[ ] Scope presented to Security TAG leadership and Sponsor is assigned
Problem: Today, open source projects do not have a consistent mechanism to publish compliance and regulatory details about what the project does in a machine readable format and to enable assessment activities to occur in an automated manner. Adopters do not have a way to understand what capabilities and controls projects have in place and what their responsibilities as consumers are as defined by the leveraged project.
Adopters today have to manually review a given software project, understand based on existing documentation if it can meet a compliance or regulatory requirement, and then determine if it does it already or if it's configurable by the adopter. They have to do this with every release. If 1 project decides to express this in one manner, another may choose a very different one and the adopter now has two ways in which they can’t reason about the compliance properties of both projects. We need a specification and guidance to allow projects to consistently and uniformly express their compliance capabilities and posture for adopters to act on.
Other areas:
Impact: Depending on the shape and nature of this project, the desired experience by adopters of cloud native projects is that when they deploy a given project the project contains sufficient metadata that in combination with a policy engine allows for decisions on whether a piece of software is permitted to be deployed in the target environment.
Such metadata shows how the project can achieve compliance (with configurations) and how it HAS achieved compliance (based on its design and operation in a given deployment environment). The evidence can also be turned over to auditors in an automated fashion to enable reasoning about system properties and conformance with regulatory requirements on a continual and ongoing basis driven by deployment frequency thereby reducing the manual audit (internal and external) activities performed by covering the technical control elements (roughly 30% of a given framework like NIST))
A lot of organizations just use hundreds of spreadsheets with 1 compliance engineer to automate. Spot checking is not good enough here.
Scope: How much effort will this take? ok to provide a range of options if or "not yet determined" for initial proposals. Feel free to include proposed tasks below or link a Google doc
Intent to lead:
Proposal to Project:
[ ] Added to the planned meeting template for mm dd
[ ] Raised in a Security TAG meeting to determine interest - mm dd
[ ] Collaborators comment on issue for determine interest and nominate project lead
[ ] Scope determined via meeting mm dd and/or shared document add link with call for participation in #tag-security slack channel thread add link and mailing list email add link
[ ] Scope presented to Security TAG leadership and Sponsor is assigned
Slack Channel
TO DO
GDoc Draft