Software Engineering Policies¶
This page records the external security and risk-management frameworks BNI references when designing, building, and reviewing software. It is a summary and pointer document, not a control checklist. Adoption of specific controls from any framework is tracked per project, with explicit validation markers.
Status: [HYPOTHESIS] for framework adoption
BNI has named these frameworks as reference standards but has not yet formally certified, audited, or self-attested compliance against any of them. Specific controls in practice today (e.g., WCAG AA, no central servers, gitignored secrets) predate this policy page; their alignment with framework controls is documented per project as it is verified. Per the Epistemic Honesty Directive, do not represent BNI software as "OWASP compliant" or "NIST aligned" in external materials without naming the specific framework version, the specific controls covered, and the validation level.
Why these frameworks¶
BNI builds software for vulnerable populations — people in recovery, reentry, elderly care, houselessness, and domestic-violence situations. The security and safety considerations for these users are not standard. We adopt established frameworks for two reasons:
- Shared language with funders, partners, and reviewers. Grants, security audits, and partner due-diligence all expect mapping to known standards.
- Cumulative wisdom. OWASP and NIST documents encode decades of incident response, attack patterns, and control design.
The frameworks below complement — they do not replace — BNI's own security and accessibility work in Security & Safety and the MPowerUP-specific threat model (see MPowerUP (migrating)).
OWASP frameworks¶
The Open Worldwide Application Security Project publishes vendor-neutral application-security guidance. BNI references three OWASP documents.
OWASP Top 10 (Web)¶
The most widely cited list of web-application security risks. Covers broken access control, cryptographic failures, injection, insecure design, security misconfiguration, and more.
Applies at BNI: the rlivn admin portal (Next.js), the umbrella docs site, any future web client. Reference: owasp.org/Top10 — current edition is OWASP Top 10:2021. A 2025 update is in development; revisit this page when finalized.
OWASP MASVS + Mobile Top 10¶
The Mobile Application Security Verification Standard (MASVS) is the mobile counterpart to ASVS, with a companion testing guide (MASTG) and a Mobile Top 10 risk list.
Applies at BNI: MPowerUP (React Native / Expo) — primary target; the rlivn tablet client (if native); any future native client distributed via Boot Up awarded hardware.
| Level | Intent |
|---|---|
| MASVS-L1 | Standard mobile app hygiene |
| MASVS-L2 | Apps handling sensitive data (health, financial, identity) — applicable to MPowerUP [HYPOTHESIS] |
| MASVS-R | Resilience against reverse engineering — separate axis, additive to L1 or L2 |
References: mas.owasp.org/MASVS · owasp.org/www-project-mobile-top-10
OWASP ASVS¶
The Application Security Verification Standard is a tiered checklist (L1, L2, L3) for self-assessment and third-party review. ASVS is the standard most often referenced in grant security questionnaires and corporate-partner due-diligence.
Applies at BNI: all web and API surfaces. Target verification level per project is [HYPOTHESIS] until budget and timeline for a formal assessment are confirmed.
Reference: owasp.org/www-project-application-security-verification-standard
NIST frameworks¶
The National Institute of Standards and Technology publishes U.S. federal cybersecurity and risk-management guidance. NIST documents are non-binding for BNI (we are not a federal contractor) but are widely cited as evidence of mature practice.
NIST SSDF — Secure Software Development Framework (SP 800-218)¶
A practice-level framework covering the full SDLC: prepare the organization, protect the software, produce well-secured software, respond to vulnerabilities. The foundation for "secure-by-design" claims.
Applies at BNI: org-wide. The four practice groups map cleanly to BNI workflows but BNI has not produced a formal practice-by-practice mapping yet [HYPOTHESIS].
Reference: csrc.nist.gov/Projects/ssdf — SP 800-218 v1.1 current.
NIST AI RMF (AI 100-1)¶
The AI Risk Management Framework provides a structured approach across four functions: Govern, Map, Measure, Manage. A Generative AI Profile (NIST AI 600-1) covers risks specific to generative systems. Applies at BNI: MPowerUP Guardian AI (Claude API + Ollama), rlivn (Claude Sonnet 4.6 + Ollama), Boot Up's AI Literacy module, and the agentic AI access mission generally — see Agentic AI Access Thesis. Reference: nist.gov/itl/ai-risk-management-framework
NIST Privacy Framework¶
A voluntary tool for managing privacy risk, structured to be compatible with the NIST Cybersecurity Framework (five functions: Identify-P, Govern-P, Control-P, Communicate-P, Protect-P). Applies at BNI: reinforces the privacy policy — privacy-by-architecture, no central servers, did:key identity, opt-in location. Reference: nist.gov/privacy-framework
Adoption status and known unknowns¶
Per the Epistemic Honesty Directive, framework adoption claims are tracked with explicit validation:
| Framework | Status | Notes |
|---|---|---|
| OWASP Top 10 (Web) | [HYPOTHESIS] |
Referenced during design; no formal self-assessment recorded |
| OWASP MASVS L2 (MPowerUP) | [HYPOTHESIS] |
Target level for MPowerUP; no audit performed |
| OWASP ASVS | [HYPOTHESIS] |
Target level per project not yet set |
| NIST SSDF | [HYPOTHESIS] |
No practice-by-practice mapping produced yet |
| NIST AI RMF | [HYPOTHESIS] |
Acknowledged in agentic-AI-access thesis; no Govern/Map/Measure/Manage artifacts yet |
| NIST Privacy Framework | [HYPOTHESIS] |
Existing privacy practices align with several Control-P subcategories; no formal mapping |
Known unknowns¶
- Whether any current or near-term funder requires a specific verification level (ASVS L1 vs. L2; SSDF self-attestation)
- Whether MPowerUP's React Native + Yjs + libp2p stack can plausibly meet MASVS-L2 controls without architectural changes
- Cost and timeline for a third-party ASVS or MASVS assessment
- Whether NIST AI RMF profiles map usefully to a small two-developer team or are scaled for larger orgs
These should be resolved before any external-facing claim of framework compliance is made.
How to apply this page¶
- When making a design decision that touches a security-sensitive surface (auth, network, storage, AI agent action), consult the relevant framework before deciding. The frameworks are a checklist for "what did we forget," not a substitute for the BNI-specific threat model.
- When writing grant or partner copy that references security or privacy posture, cite specific framework documents by name and version, mark validation honestly, and link back to this page.
- When a framework publishes a new revision, update this page and flag the change.