Add security foundations section #487
Conversation
|
No New Or Fixed Issues Found |
Deploying contributing-docs with
|
| Latest commit: |
0222f3f
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://94659174.contributing-docs.pages.dev |
| Branch Preview URL: | https://ps-add-fundamental-reqs.contributing-docs.pages.dev |
| The requirements in this section are organized hierarchically, with top-level requirements defining | ||
| the core rules and obligations that must be met, serving as broad objectives for Bitwarden's | ||
| security model. Sub-requirements expand on these by addressing specific scenarios, exceptions, or | ||
| clarifications, and may override their parent requirement when explicitly stated. Sibling | ||
| requirements at the same level must remain independent and free of contradictions. |
There was a problem hiding this comment.
thought: Might be nice to align this to an industry standard like ISO/IEC/IEEE 29148, but there's only so much we can do in a markdown document
| 2. Vault data **MAY** be unprotected while _in use_. | ||
|
|
||
| - a. The Client **MAY** decrypt all vault data during vault unlock. | ||
| - i. The Client **SHOULD** minimize the quantity of decrypted vault data. |
There was a problem hiding this comment.
thought: we could make this more stringent
| - i. The Client **SHOULD** minimize the quantity of decrypted vault data. | |
| - i. The Client **SHOULD** limit decrypted data to the records actively in use by the user. |
| @@ -0,0 +1,21 @@ | |||
| # P03 - No security on fully compromised systems | |||
There was a problem hiding this comment.
point-of-interest: this was previously called No guarantees for unlocked vaults on fully compromised devices. I changed it to make it more consistent with the other principles, but "no security" might seems a bit harsh
|
Thoughts on dropping the acronyms and typed declarations? "P01" and "EK" come off rather strongly to me. Same for the "MUST" and "MUST NOT" all over the place that could probably just be expressed without capitalization and boldface. |
|
@withinfocus for The boldface might be distracting you're probably right, but I'm not sure about removing the capitalization. Here I'm drawing inspiration from W3C specifications such as WebAuthn L3 where those terms are always captialized |
|
I get where you're coming from with the historical references, but I see those as specifications with a large scope and impact. This is important to the company as principles, but I wouldn't treat it quite so intensely such as to model it vs. writing natural language. |
|
Imo: I prefer the RFC-like MUST NOT, and SHOULD NOT, etc. because it makes it clear that we are unambiguous and very deliberate about whatever meaning we encode with them, because they have a clear definition (from rfc2119). So, if we want to treat this as a set of requirements, that we want to design our applications by, then the RFC-style terms helps make these requirements unambiguous and clear. |
|
My vision was that these requirements would be what we base all of our security design on, and not be "mere guidelines". If that will happen or not is probably beyond the scope of this PR. :) That said, the primary reason that motivated me to create this documentation was to remove ambiguousness surrounding security design and make it very clear for teams that have to design solutions for our products. Given that I am hesitant to make any changes that could potentially decrease clarity and introduce ambiguousness |
🎟️ Tracking
📔 Objective
This ports over an internal document while making some adjustments to the principles. Requirements will initially be added as-is
⏰ Reminders before review
team
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmedissue and could potentially benefit from discussion
:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes