SECURITY
Effective February 20, 2026
·
Review February 20, 2027
·
Security Lead
Vulnerability Management Procedure
Organization: Aina Design Corp
Applies To: hawaii.mokunet.us · kuleana.ainadesign.org · huikoeaina.ainadesign.org · ainadesign.org
Version: 1.0
Effective Date: February 20, 2026
Next Review: February 20, 2027
Policy Owner: Security Lead
1. Purpose
This procedure defines how Aina Design Corp identifies, assesses, prioritizes, and remediates security vulnerabilities in its platforms and dependencies — ensuring that student data is protected from known exploits and that district partners can trust the security posture of the platforms they use.
2. Scope
This procedure applies to:
•
All platform codebases (mokunet, kuleana, huikoeaina, ainadesign.org)
•
All third-party libraries and dependencies
•
All cloud infrastructure and configuration
•
All Firebase, Supabase, and hosting configurations
3. Vulnerability Sources
Aina Design Corp monitors for vulnerabilities from the following sources:
Source
Method
Frequency
Dependency scanning
npm audit, automated CI checks
Every pull request + weekly
CVE databases
Subscription to CISA KEV catalog
Weekly
Security advisories
GitHub Dependabot alerts
Continuous
Penetration testing
Third-party assessment
Annually
Internal code review
OWASP-aligned peer review
Every pull request
4. Severity Classification and Response Times
Severity
Definition
Remediation Target
Critical
CVSS 9.0–10.0; remote code execution, auth bypass
Patch within 24 hours; notify district partners
High
CVSS 7.0–8.9; significant data exposure risk
Patch within 7 days
Medium
CVSS 4.0–6.9; limited or indirect risk
Patch within 30 days
Low
CVSS < 4.0; minimal risk
Address in next scheduled release
If a critical vulnerability cannot be patched within 24 hours, a documented compensating control (e.g., WAF rule, feature flag disablement) must be applied and the Security Lead notified.
5. Vulnerability Workflow
1.
Identify — Vulnerability detected via automated scan, advisory, or manual review.
2.
Assess — Security Lead confirms severity and affected systems.
3.
Prioritize — Assign remediation owner and target date based on severity table above.
4.
Remediate — Apply patch or implement compensating control.
5.
Verify — Confirm fix is deployed and vulnerability is resolved.
6.
Document — Record the vulnerability, assessment, remediation action, and closure date in the risk register.
7.
Notify (if applicable) — Notify district partners if a high/critical vulnerability may have exposed their data.
6. Dependency Management
•
All production dependencies are tracked in package.json with locked versions.
•
Dependabot or equivalent is enabled on all repositories.
•
Dependencies with no available patch for a critical vulnerability are evaluated for replacement or isolation.
•
No dependency may be pinned to a known-vulnerable version without a documented risk acceptance from the Security Lead.
7. Secure Development Controls
All code changes pass through:
•
Automated dependency scanning in CI/CD pipeline
•
Peer code review (OWASP Top 10 awareness required)
•
Security-focused release checklist before production deployment
8. Risk Acceptance
Where a vulnerability cannot be remediated within the target timeframe, a formal risk acceptance is documented by the Security Lead. Risk acceptances expire after 90 days and must be renewed with justification.
9. Review Cadence
•
Weekly: Automated scan results reviewed
•
Monthly: Open vulnerability register reviewed
•
Annually: Full procedure review
10. Sign-Off
Security Lead: _________________________
Engineering Lead: _________________________
Date Approved: _________________________