Review Secure Development Knowledge in community

[dcmiddle]

From https://bestpractices.coreinfrastructure.org/en/projects/5719#security

The project MUST have at least one primary developer who knows how to design secure software. (See ‘details’ for the exact requirements.) [know_secure_design]
This requires understanding the following design principles, including the 8 principles from Saltzer and Schroeder:

• economy of mechanism (keep the design as simple and small as practical, e.g., by adopting sweeping simplifications)

• fail-safe defaults (access decisions should deny by default, and projects' installation should be secure by default)

• complete mediation (every access that might be limited must be checked for authority and be non-bypassable)

• open design (security mechanisms should not depend on attacker ignorance of its design, but instead on more easily protected and changed information like keys and passwords)

• separation of privilege (ideally, access to important objects should depend on more than one condition, so that defeating one protection system won't enable complete access. E.G., multi-factor authentication, such as requiring both a password and a hardware token, is stronger than single-factor authentication)

• least privilege (processes should operate with the least privilege necessary)

• least common mechanism (the design should minimize the mechanisms common to more than one user and depended on by all users, e.g., directories for temporary files)

• psychological acceptability (the human interface must be designed for ease of use - designing for "least astonishment" can help)

• limited attack surface (the attack surface - the set of the different points where an attacker can try to enter or extract data - should be limited)

• input validation with allowlists (inputs should typically be checked to determine if they are valid before they are accepted; this validation should use allowlists (which only accept known-good values), not denylists (which attempt to list known-bad values)).

Additionally from Other security issues in the same section...

The public repositories MUST NOT leak a valid private credential (e.g., a working password or private key) that is intended to limit public access. [no_leaked_credentials]

A "primary developer" in a project is anyone who is familiar with the project's code base, is comfortable making changes to it, and is acknowledged as such by most other participants in the project. A primary developer would typically make a number of contributions over the past year (via code, documentation, or answering questions). Developers would typically be considered primary developers if they initiated the project (and have not left the project more than three years ago), have the option of receiving information on a private vulnerability reporting channel (if there is one), can accept commits on behalf of the project, or perform final releases of the project software. If there is only one developer, that individual is the primary developer. Many books and courses are available to help you understand how to develop more secure software and discuss design. For example, the Secure Software Development Fundamentals course is a free set of three courses that explain how to develop more secure software (it's free if you audit it; for an extra fee you can earn a certificate to prove you learned the material).

Review these topics in the community. Consider using asynchronous means like acknowledgement of this issue or discussion in a community meeting.

[dcmiddle]

Each component should have a maintainer familiar with the content listed in this issue.
Each component please list here at least one maintainer responsible for security code reviews.

[dcmiddle]

@confidential-containers/attestation-agent-maintainers
@confidential-containers/attestation-service-maintainers
@confidential-containers/cc-shim-maintainers
@confidential-containers/enclave-cc-maintainers
@confidential-containers/image-maintainers
@confidential-containers/kbs-maintainers
@confidential-containers/peer-pod-maintainers
Please list the maintainer acting as the security champion for your component.

[dcmiddle]

• attestation-agent:
• attestation-service:
• cc-shim:
• enclave-cc: @dcmiddle
• image-rs, ocicrypt-rs:
• kbs:
• operator:
• peer-pod:

[jyao1]

• attestation-agent:
• attestation-service:
• cc-shim: @jyao1
• enclave-cc: @dcmiddle
• image-rs, ocicrypt-rs:
• kbs:
• operator:
• peer-pod:

[fitzthum]

• attestation-agent: @fitzthum
• attestation-service:
• cc-shim: @jyao1
• enclave-cc: @dcmiddle
• image-rs, ocicrypt-rs:
• kbs:
• operator:
• peer-pod:

[dcmiddle]

@arronwy do you satisfy these criteria for image-rs & ocicrypt-rs?

[dcmiddle]

With 3 of us responding, I've updated the badge to reflect we are meeting this requirement.
I will close the issue once all components here have security champions.

[arronwy]

@arronwy do you satisfy these criteria for image-rs & ocicrypt-rs?

sure, thanks for the summary of these criteria.

• attestation-agent: @fitzthum
• attestation-service:
• cc-shim: @jyao1
• enclave-cc: @dcmiddle
• image-rs, ocicrypt-rs: @arronwy
• kbs:
• operator:
• peer-pod:

[ariel-adam]

@dcmiddle is this issue still relevant or can be closed?
If it's still relevant to what release do you think we should map it to (mid-November, end-December, mid-February etc...)?

[dcmiddle]

I think we covered our bases for v0.1.
Uncovered components/repos need security champions for v0.2

[ariel-adam]

@dcmiddle do you think this can converge for the V0.3.0 release?

[dcmiddle]

Thanks for the ping @ariel-adam .. I added a call for security champions for the remaining components to the community agenda 12/18.

[sameo]

• attestation-agent: @fitzthum
• attestation-service: @sameo (with @jialez0 @Xynnn007 if they're ok with it)
• cc-shim: @jyao1
• enclave-cc: @dcmiddle
• image-rs, ocicrypt-rs: @arronwy
• kbs: @sameo (and @jialez0 if he's fine with it)
• operator:
• peer-pod:

[ariel-adam]

@dcmiddle can I move this issue into progress?

[ariel-adam]

Do you feel this is still on track for V0.3.0 or should we role this to the next release?

[bpradipt]

• attestation-agent: @fitzthum
• attestation-service: @sameo (with @jialez0 @Xynnn007 if they're ok with it)
• cc-shim: @jyao1
• enclave-cc: @dcmiddle
• image-rs, ocicrypt-rs: @arronwy
• kbs: @sameo (and @jialez0 if he's fine with it)
• operator: @fidencio and @bpradipt
• peer-pod:

[magowan]

• attestation-agent: @fitzthum
• attestation-service: @sameo (with @jialez0 @Xynnn007 if they're ok with it)
• cc-shim: @jyao1
• enclave-cc: @dcmiddle
• image-rs, ocicrypt-rs: @arronwy
• kbs: @sameo (and @jialez0 if he's fine with it)
• operator: @fidencio and @bpradipt
• peer-pod: @magowan and @stevenhorsman

[dcmiddle]

Complete for all components designated for v0.3. Badge updated. Should we add new components we can reopen this.