Skip to content

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:

  1. Shared language with funders, partners, and reviewers. Grants, security audits, and partner due-diligence all expect mapping to known standards.
  2. Cumulative wisdom. OWASP and NIST documents encode decades of incident response, attack patterns, and control design. We do not need to rediscover them.

The frameworks below complement — they do not replace — the BNI-specific Threat Model, Authentication & Lockout, and Accessibility Framework.

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, updated every few years. Covers issues like broken access control, cryptographic failures, injection, insecure design, and security misconfiguration.

Where it applies at BNI:

  • rlivn admin portal (Next.js)
  • BNI umbrella docs site (static, but still a web surface)
  • Any future web client built on the open ecosystem

Reference: owasp.org/Top10 — current edition is OWASP Top 10:2021. A 2025 update is in development; this page should be revisited when it is 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.

Where it applies at BNI:

  • MPowerUP (React Native / Expo) — primary target
  • rlivn tablet client (if it ships as a native app rather than a web-app-on-device)
  • Any future native client distributed via Second Boot awarded hardware

MASVS verification levels:

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:

OWASP ASVS

The Application Security Verification Standard is a tiered checklist (L1, L2, L3) used for both self-assessment and third-party security review. ASVS is the standard most often referenced in grant security questionnaires and corporate-partner due-diligence forms.

Where it 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 software development lifecycle: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities. SSDF is the foundation for "secure-by-design" claims.

Where it applies at BNI: Org-wide. The four practice groups map cleanly to BNI workflows (PO/PS/PW/RV in SSDF notation) but BNI has not produced a formal practice-by-practice mapping yet [HYPOTHESIS].

Reference: csrc.nist.gov/Projects/ssdf — SP 800-218 v1.1 is the current revision.

NIST AI RMF (AI 100-1)

The AI Risk Management Framework provides a structured approach to identifying, measuring, and managing AI-system risk across four functions: Govern, Map, Measure, Manage. NIST has also published a Generative AI Profile (NIST AI 600-1) covering risks specific to generative systems.

Where it applies at BNI:

  • MPowerUP Guardian AI (Claude API + Ollama)
  • rlivn (Claude Sonnet 4.6 + Ollama)
  • Second Boot Module 04 (AI Literacy curriculum)
  • The agentic AI access mission generally — see Agentic AI Access Thesis

Reference: nist.gov/itl/ai-risk-management-framework — AI 100-1 is the core document; AI 600-1 is the Generative AI Profile.

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.

Where it applies at BNI: Reinforces the Privacy section in Policies — privacy-by-architecture, no central servers, did:key identity, opt-in location. Relevant to vulnerable-population framing in grant applications and partner conversations.

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 (OWASP Top 10 next edition, SSDF revision), update this page and flag the change in Notes.