-
Notifications
You must be signed in to change notification settings - Fork 27
Update faq.md - What is in scope for the Open Source Project Security Baseline, and what is out of scope ? #333
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Worked together with @eddie-knight on this change. Signed-off-by: victorjunlu <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Explaining with an analogy was a good idea
Signed-off-by: victorjunlu <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution, @victorjunlu!
Before I get to the substance, a style note: although we don't have a formal style guide yet, you'll note that this file uses a one-line-per-sentence style. As you address other feedback, please update your PR to reflect that.
To the substance: It's not clear to me that "secure development" is out of scope. Or at least, what it means differently from "security hygiene." Looking through the controls, I see several that would seem to fit in your analogy as "out of scope"
I'd also argue that things like dependency selection (which is covered in the OSPS Baseline) falls into the "decide how the house is constructed" part of your analogy.
To me, the analogy reduces clarity.
It could be that the solution is to remove some of the controls because they're out of scope. I'm not sure I agree with that, but I'm open to the argument. But in any case, I don't think this FAQ entry matches the current reality, so one or both of them will need to be adjusted.
I'm not attached to this FAQ entry, but I do think it's accurate.
These items don't evaluate efficacy or content, just that a best practice has been done. ie, We're not checking the quality of your blueprint... just making sure that you have one on record with the city. |
That's what's not reflected in the proposed text. Adding some clarity along those lines would go a long way toward addressing my concerns. I also am wondering if in/out of scope is the best way to express this question, but I don't have fully-formed thoughts here yet. Before I opened the actual diff, I assumed it was going to be about projects/deliverables that Baseline does or does not apply to. If I think of a suggestion for a different way to phrase the question, I'll add it as a comment. If I don't, then 🤷 |
This baseline seeks to address security hygiene elements — those which lock down the ways of working, delivering the product, and equipping its users to adopt it safely. To use an analogy, it’s like home builders who lock up tools, secure the construction site, and control who enters, but also ensure the finished house is handed over with clear instructions for safe use. It’s not about changing the blueprint—it’s about protecting the build process and delivering a home that’s ready to live in securely. | ||
|
||
By contrast, secure design and development are out of scope for this activity. Continuing the analogy, those activities would be the responsibility of the architects and builders who create the blueprint and decide how the house is constructed to prevent break-ins—with reinforced doors, secure locks, strategic layouts/no backdoor, or built-in security systems. It’s about designing security into the structure itself, not just safeguarding the build and handoff. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This baseline seeks to address security hygiene elements — those which lock down the ways of working, delivering the product, and equipping its users to adopt it safely. To use an analogy, it’s like home builders who lock up tools, secure the construction site, and control who enters, but also ensure the finished house is handed over with clear instructions for safe use. It’s not about changing the blueprint—it’s about protecting the build process and delivering a home that’s ready to live in securely. | |
By contrast, secure design and development are out of scope for this activity. Continuing the analogy, those activities would be the responsibility of the architects and builders who create the blueprint and decide how the house is constructed to prevent break-ins—with reinforced doors, secure locks, strategic layouts/no backdoor, or built-in security systems. It’s about designing security into the structure itself, not just safeguarding the build and handoff. | |
This baseline seeks to address security hygiene elements — those which lock down the ways of working, delivering the product, and equipping its users to adopt it safely. | |
To use an analogy, it’s like home builders who lock up tools, secure the construction site, and control who enters, but also ensure the finished house is handed over with clear instructions for safe use. | |
We're not checking the quality of your blueprint... just making sure that you have one on record with the city. | |
Design and development are part of the [assessment](https://github.com/ossf/security-assessments) activity, which is comparable to evaluating the blueprint of a home before it is constructed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I like the term "lock down" here (even if we're talking about controls, I prefer to think of it as "defending against yourself on your worst days"). How about:
The baseline seeks to address security hygiene practices — much like workspace and product safety requirements in other domains. Using a construction analogy, baseline is similar to the jobsite rules and processes (hard hats, fencing, etc) a builder uses to prevent injuries to workers as they are building a house, and also covers the documentation standards used to provide operation and maintenance instructions for the final owner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think some combination of Eddie's and Evan's suggestions are the right answer here. Let's see if I can come up with a good blend. :-)
Worked together with @eddie-knight on this change.
What is in scope for the Open Source Project Security Baseline, and what is out of scope ?