[Proposal] Security "Nutrition" Labels

[jlk]

trafficstars

Description: A security "nutrition label" and project badge offers a standardized way to communicate particulars related to the security of a project to potential users - if it requires administrative privileges, documentation, design...really the security maturity of the project.

The idea here is that nutrition labels or badges would be rendered from a machine-readable format, such as YAML. This would other potential usage such as validation during CI, perhaps at runtime with an admission controller.

Impact: This proposal would provide project maintainers a standardized way to communicate, and users a way to easily understand, the security requirements and status of a project.

Scope: My sense from feedback on my talk is there's enough interest to form a working group and build out the idea, and figure out how this could be run efficiently as a service.

I did a CN security day talk at kubecon EU 2021 on this topic; slides and examples are available at https://github.com/jlk/nutrition_labels. When the video's on YT I'll add a link.

TO DO

• [ ] STAG Sponsor: @achetal01
• [ ] Project leader(s) (I'm happy to lead, co-lead, whatever)
• [ ] Promote working group
• [ ] Discuss and further build out the idea
• [ ] Determine implementation, outreach, adoption, etc
• [ ] ...
• [ ] Profit

[metahertz]

+1

Was speaking with @jlk on this via Slack, capturing here:

following research into the default security posture of public helm charts, scanning artifacthub and crunching some data. I keep coming back to the conclusion that we ideally need to signal a “persona” for re-usable objects such as Charts, as the persona changes the acceptable security posture for a given object, this could be included in the nutrition data, (or at least as part of the same conversation: keeping the foody-theme, almost like the “suitable for” sticker on the product label.)

For example:

1. An app deployment or service, which runs on kubernetes should never (or very very rarely) need extra privs, default service tokens, CAP_NET capabilities etc.

Inversely

2. An app which extends or provides part of the kubernetes platform itself (Logging, monitoring, CNI, Storage plugins etc etc) may reasonably need all of those things.

And yet, both are public helm charts and deployed the same way, so a SAST security scans are either going to be too noisy if the ruleset is designed for (1) or way too permissive if designed for (2). Context gives us the key.

[jlk]

One "real world" datapoint on this - I see Kubewarden's policy hub is using keyword tags to indicate what policies control privileged containers, PSPs, etc. Almost an inverse nutrition label/badge, but it does show a use case that being able to search on these things has value to people...

[jlk]

OSSF released v2 of their security scorecard project. Looks interesting, although the end user has to run a scan, vs the nutrition label idea that the project announce it's status.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had recent activity.

[lumjjb]

commenting to remove first stale label

[stale[bot]]

This issue has been automatically marked as inactive because it has not had recent activity.

[anvega]

A lot of merit to this idea. As pointed out, the scorecard implements some of it, although it could be improved so it runs automatically by the project and is advertised as a status. Closing the issue as the proposal didn't get hold within the context of the tag and seems more like an issue for improvement of the scorecard. Feel free to reopen if you disagree with my assessment here.