openshield-org · Vishnu2707 · Jul 18, 2026 · Jul 16, 2026
@@ -26,9 +26,10 @@ The more detail you provide, the faster we can respond.
 
 | Version | Supported |
 |---------|-----------|
-| 0.1.x   | Yes       |
+| 0.3.x   | Yes       |
+| 0.1.x   | No        |
 
-Older versions are not patched. If you are running a version below 0.1.x, upgrade to the latest release before filing a report.
+Older versions are not patched unless a GitHub Security Advisory explicitly says otherwise. Upgrade to the latest release before filing a report.
 
 ---
 
@@ -71,12 +72,12 @@ We ask that you do not publicly disclose the vulnerability until step 6 is compl
 We value responsible disclosure. Researchers who report valid vulnerabilities will be:
 
 - Acknowledged by name (or pseudonym if preferred) in the release notes for the fix
-- Listed in a `SECURITY_ACKNOWLEDGEMENTS.md` file we maintain in this repository
+- Listed in [`SECURITY_ACKNOWLEDGEMENTS.md`](../SECURITY_ACKNOWLEDGEMENTS.md)
 
 We do not currently offer a bug bounty programme, but we are grateful for every report.
 
 ---
 
 ## Contact
 
-**Email: vishnu.ajith@owasp.org**
+**Email: vishnu.ajith@owasp.org**
@@ -531,7 +531,7 @@ jobs:
         env:
           DATABASE_URL: "postgresql://ci:ci@localhost:5432/ci_db"
         run: |
-          pytest tests/ -v --tb=short --cov=api --cov=scanner --cov-report=term --cov-report=xml --cov-fail-under=25
+          pytest tests/ -v --tb=short --cov=api --cov=scanner --cov-report=term --cov-report=xml --cov-fail-under=80
 
   # ── Frontend lint + build ────────────────────────────────────────────────
   frontend:

@@ -218,7 +218,7 @@ pip install -r requirements.txt
 # Installs Flask, Alembic, Azure SDK clients, requests, psycopg2, PyJWT, and PyYAML for CI workflow validation.
 
 # Frontend
-# The frontend directory is currently a scaffold. The React dashboard MVP is on the roadmap.
+# The React dashboard lives in frontend/ and uses the repository's npm scripts.
 
 # Database (Docker)
 docker run --name openshield-db \
@@ -268,6 +268,12 @@ All contributions must meet these standards before a pull request will be review
 - Follow Conventional Commits using prefixes such as `feat:`, `fix:`, `docs:`, `chore:`, and `test:`.
 - Reference the related issue number where applicable.
 
+**Developer Certificate of Origin**
+
+- By adding `Signed-off-by: Your Name <email>` to a commit, a contributor certifies the [Developer Certificate of Origin 1.1](https://developercertificate.org/).
+- Use `git commit -s` to add the sign-off.
+- The project lead must approve and enable DCO enforcement before this becomes a required merge check; until then, sign-off is requested but not represented as enforced.
+
 **Branch naming**
 
 - Use `feat/description` for new features.
@@ -285,6 +291,7 @@ All contributions must meet these standards before a pull request will be review
 - Add a CLI remediation playbook for each new scanner rule.
 - Follow `.github/PULL_REQUEST_TEMPLATE.md`.
 - Obtain at least one reviewer approval before merge.
+- Add regression tests for bug fixes whenever the behavior can be reproduced automatically. Major functionality must include automated tests.
 
 ## OpenSSF Best Practices
 

@@ -0,0 +1,62 @@
+# OpenShield Governance
+
+OpenShield uses a maintainer-led, consensus-seeking governance model. Technical
+discussion happens in public GitHub issues and pull requests. The maintainers
+seek agreement through review; when consensus cannot be reached, the project
+lead makes the final decision and records the reasoning publicly.
+
+## Roles
+
+- **Project lead:** sets project direction, appoints maintainers, manages
+  releases and resolves decisions that cannot reach consensus.
+- **Maintainers:** triage issues, review changes, uphold security and quality
+  requirements, and merge approved pull requests in their assigned areas.
+- **Security maintainers:** privately triage vulnerability reports, coordinate
+  fixes and advisories, and ensure reporter credit is handled according to the
+  security policy.
+- **Contributors:** propose issues and changes, participate in review, add tests
+  and documentation, and follow the Code of Conduct and contribution policy.
+
+Current role holders and component responsibilities are listed in
+[`MAINTAINERS.md`](MAINTAINERS.md). Repository paths also have review owners in
+`.github/CODEOWNERS`.
+
+## Decision and change process
+
+1. Material changes begin with a GitHub issue describing the problem, scope and
+   acceptance criteria.
+2. Implementation is submitted by pull request to `dev` and must pass required
+   automated checks.
+3. At least one qualified reviewer must approve before merge. Authors do not
+   approve their own changes.
+4. Releases are promoted from `dev` to `main` and published by an authorized
+   maintainer.
+5. Security-sensitive decisions may be discussed privately until coordinated
+   disclosure, after which the advisory and fix are made public.
+
+## Appointing and removing maintainers
+
+Regular contributors may be nominated as maintainers based on sustained,
+constructive work and demonstrated knowledge of the relevant component. The
+project lead confirms appointments after consulting existing maintainers.
+Maintainers may step down at any time. Access may be removed for inactivity,
+security risk, repeated policy violations, or Code of Conduct violations.
+
+## Continuity
+
+The project intends to maintain at least two people capable of issue triage,
+pull-request review, merging and release operations. Administrative access,
+deployment access, domains and recovery methods must be held through
+organization-controlled accounts or recoverable records rather than a single
+person's undocumented credentials.
+
+The project lead reviews continuity access before each release. The names of
+people who currently hold each capability are intentionally confirmed through
+private organization records; `MAINTAINERS.md` lists the public accountable
+roles without publishing secret locations or recovery details.
+
+## Governance changes
+
+Governance changes use the normal issue and pull-request process and require
+approval from the project lead and one additional maintainer. Emergency
+security changes may be merged first and documented immediately afterward.
@@ -0,0 +1,25 @@
+# OpenShield Maintainers
+
+This file identifies public project roles and responsibilities. It does not
+assert organization permissions that have not been confirmed by the project
+lead.
+
+| Role | Account | Responsibilities |
+|---|---|---|
+| Project lead and release owner | [@Vishnu2707](https://github.com/Vishnu2707) | Direction, final governance decisions, releases and organization administration |
+| Scanner and playbook maintainer | [@TFT444](https://github.com/TFT444) | Azure scanner rules, remediation playbooks, tests and review |
+| Scanner and compliance maintainer | [@SHAURYAKSHARMA24](https://github.com/SHAURYAKSHARMA24) | Scanner rules, playbooks and compliance mappings |
+| API and AI maintainer | [@ritiksah141](https://github.com/ritiksah141) | API, AI layer, CI/infra review and backend tests |
+| Frontend maintainer | [@vogonPrayas](https://github.com/vogonPrayas) | Dashboard implementation and frontend review |
+| Test maintainer | [@parthrohit22](https://github.com/parthrohit22) | Test suite and documentation review |
+
+Path-specific review assignments are maintained in `.github/CODEOWNERS`.
+Private security reports are coordinated using `.github/SECURITY.md`.
+
+## Owner confirmation required
+
+Before OpenShield claims the OpenSSF continuity criteria, the project lead must
+confirm that at least two people can perform issue administration, merge
+approved changes and publish a release if any one maintainer becomes
+unavailable. Public role assignment alone is not proof of administrative
+access.
@@ -48,10 +48,10 @@ Findings map to NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA
 
 | Feature | Description |
 |---|---|
-| **Misconfiguration Scanner** | Runs 39 Azure security rules across storage, network, identity, database, compute, Key Vault, and post-quantum cryptography |
+| **Misconfiguration Scanner** | Runs 51 Azure security rules across storage, network, identity, database, compute, Key Vault, AKS, and post-quantum cryptography |
 | **Compliance Mapper** | Maps findings to CIS Benchmarks, NIST CSF, ISO 27001, and SOC 2 framework JSON files |
 | **Scan History API** | Stores scans and findings in PostgreSQL and exposes findings, score, scan history, compliance posture, drift, and resource inventory over REST |
-| **Remediation Playbooks** | Every rule ships with a matching Azure CLI remediation script (36 playbooks) |
+| **Remediation Playbooks** | Every rule ships with a matching Azure CLI remediation script (51 playbooks) |
 | **Security Dashboard** | Full React dashboard deployed on Vercel - live monitoring, findings, compliance, drift, prioritization, and AI-layer views |
 | **Project Website** | Documentation and reference site at [openshield-website.vercel.app](https://openshield-website.vercel.app) - blog, rules gallery, docs, roadmap, releases, and interactive playground |
 | **Sentinel Integration** | Normalises findings and pushes them into Microsoft Sentinel via a Log Analytics custom table and KQL analytics rules |
@@ -76,6 +76,15 @@ The project's OpenSSF status is publicly verifiable through the official OpenSSF
 
 **[View OpenShield's verified OpenSSF Best Practices record](https://www.bestpractices.dev/projects/13618)**
 
+Project policies and assurance evidence:
+
+- [Governance](GOVERNANCE.md) and [maintainer responsibilities](MAINTAINERS.md)
+- [July 2026–June 2027 roadmap](ROADMAP.md)
+- [Support and upgrade policy](SUPPORT.md)
+- [Security requirements](docs/security-requirements.md) and [security assurance case](docs/security-assurance-case.md)
+- [Release security](docs/release-security.md) and [accessibility/i18n policy](docs/accessibility-and-i18n.md)
+- [OpenSSF Silver evidence register](docs/openssf-silver-evidence.md)
+
 ---
 
 ## Architecture
@@ -84,11 +93,11 @@ The project's OpenSSF status is publicly verifiable through the official OpenSSF
 flowchart TD
     A["React Dashboard\nVercel · Live"]
     B["Flask REST API\nJWT · CORS · Blueprints"]
-    C["Scanner Engine\n39 Python rules"]
+    C["Scanner Engine\n51 Python rules"]
     D["Azure Subscription\nScanned via Azure SDK + Graph"]
     E["Compliance Framework JSON\nCIS · NIST · ISO 27001 · SOC 2"]
     F["PostgreSQL Database\nFindings · Scans"]
-    G["Azure CLI Playbooks\n39 remediation scripts"]
+    G["Azure CLI Playbooks\n51 remediation scripts"]
     H["sentinel/ingest.py\nNormalise + HMAC upload"]
     I["Microsoft Sentinel\nOpenShieldFindings_CL · KQL rules"]
 

@@ -0,0 +1,43 @@
+# OpenShield Roadmap: July 2026 to June 2027
+
+This roadmap communicates direction rather than a delivery guarantee. Security
+fixes and community needs may change priorities. Work is accepted only through
+reviewed issues and pull requests.
+
+## July–September 2026
+
+- Complete OpenSSF Best Practices Silver readiness and evidence.
+- Expand enterprise Azure coverage while preserving low false-positive rates.
+- Improve scanner inventory error handling and rule test coverage.
+- Reconcile documentation, website rule counts and current APIs.
+
+## October–December 2026
+
+- Stabilize the scanner and REST API contracts for a supported 1.0 release.
+- Improve deployment, upgrade and database migration guidance.
+- Expand Sentinel detections and operational security monitoring.
+- Establish signed release artifacts and public verification instructions.
+
+## January–March 2027
+
+- Add organization-scale scanning and clearer multi-subscription workflows.
+- Improve accessibility and internationalization readiness in user interfaces.
+- Expand evidence-based compliance reporting and exception handling.
+- Evaluate a provider interface for future clouds without weakening Azure
+  support.
+
+## April–June 2027
+
+- Review reliability, performance and recovery objectives using production
+  feedback.
+- Mature compatibility, deprecation and long-term maintenance policies.
+- Reassess readiness for OpenSSF Gold without claiming it prematurely.
+
+## Explicitly out of scope for this period
+
+- Automatic remediation without explicit operator confirmation.
+- Claims of formal certification for CIS, ISO 27001, SOC 2 or NIST.
+- Collection of Azure resource contents, secrets or customer workload data.
+- Guaranteed detection of every cloud vulnerability or configuration risk.
+- Multi-cloud parity until the Azure implementation and provider boundary are
+  stable.
@@ -0,0 +1,9 @@
+# Security Acknowledgements
+
+OpenShield credits reporters of resolved vulnerabilities unless they request
+anonymity. Credits are added here and to the relevant security advisory or
+release notes after coordinated disclosure.
+
+No externally reported vulnerability has been publicly disclosed by the project
+as of 16 July 2026. This statement should be updated whenever a coordinated
+disclosure is completed.
@@ -0,0 +1,30 @@
+# Support and Version Policy
+
+## Supported releases
+
+OpenShield supports the latest published minor release. Security fixes may also
+be issued for the immediately preceding minor release when an upgrade cannot be
+completed promptly. Older releases are unsupported unless a GitHub Security
+Advisory explicitly states otherwise.
+
+The authoritative release list is the project's GitHub Releases page. Users
+should include the release tag or commit SHA when reporting a defect.
+
+## Upgrading
+
+1. Read `CHANGELOG.md` and the target GitHub Release notes.
+2. Back up the database and deployment configuration.
+3. Install the target source and its pinned dependency manifests.
+4. Run `alembic upgrade head` before starting the API.
+5. Validate `/health`, authentication, scanning and dashboard connectivity in a
+   non-production environment before promotion.
+
+Database-specific migration instructions are in
+`docs/database-migrations.md`. Breaking changes and required operator actions
+must be identified in release notes.
+
+## Security support
+
+Do not report vulnerabilities through a public issue. Follow
+`.github/SECURITY.md` for the private reporting and coordinated disclosure
+process.
@@ -0,0 +1,13 @@
+# Accessibility and Internationalization
+
+OpenShield aims for keyboard-operable interfaces, visible focus, semantic HTML,
+text alternatives for meaningful images, labeled controls, adequate contrast,
+responsive layouts and reduced-motion compatibility where practical. New UI
+changes should be reviewed against WCAG 2.2 AA guidance and tested with keyboard
+navigation. Accessibility defects are tracked like other product defects.
+
+English is currently the only supported interface language. User-facing text
+should be kept separate from security data and logic where practical so a
+future localization system can replace it without changing scanner behavior.
+OpenShield must not claim full internationalization until the frontend and
+website use message catalogs, locale-aware formatting and localization tests.
@@ -2,7 +2,7 @@
 
 ## Overview
 
-OpenShield is a modular, open source Cloud Security Posture Management (CSPM) platform for Azure. It scans your Azure subscription against 36 security rules, maps findings to compliance frameworks (CIS, NIST CSF, ISO 27001, SOC 2), stores results in PostgreSQL, and exposes posture data through a Flask REST API consumed by a live React dashboard.
+OpenShield is a modular, open source Cloud Security Posture Management (CSPM) platform for Azure. It scans your Azure subscription against 51 security rules, maps findings to compliance frameworks (CIS, NIST CSF, ISO 27001, SOC 2), stores results in PostgreSQL, and exposes posture data through a Flask REST API consumed by a live React dashboard.
 
 ---
 
@@ -43,8 +43,8 @@ OpenShield is a modular, open source Cloud Security Posture Management (CSPM) pl
 ┌───────────▼──────────────────────────────────────────────────────┐
 │                   Rule Modules (scanner/rules/)                   │
 │                                                                   │
-│  20 rule files across Storage, Network, Identity, Database,       │
-│  Compute, and Key Vault                                           │
+│  51 rule files across Storage, Network, Identity, Database,       │
+│  Compute, Key Vault, AKS, and post-quantum cryptography           │
 └───────────┬───────────────────────────────────────────────────────┘
             │ calls
 ┌───────────▼──────────────────────────────────────────────────────┐
@@ -110,16 +110,18 @@ result = engine.run_scan()
 
 ### 4. Current Rule Modules
 
-There are 36 rule files in `scanner/rules/`. See `docs/rules-reference.md` for the full table.
+There are 51 rule files in `scanner/rules/`. See `docs/rules-reference.md` for the full table.
 
 | Category | Count | Rules |
 |---|---|---|
 | Storage | 5 | AZ-STOR-001 to 005 |
-| Network | 14 | AZ-NET-001 to 014 |
+| Network | 15 | AZ-NET-001 to 015 |
 | Identity | 4 | AZ-IDN-001 to 004 |
 | Database | 4 | AZ-DB-001 to 004 |
 | Compute | 4 | AZ-CMP-001 to 004 |
 | Key Vault | 5 | AZ-KV-001 to 005 |
+| Kubernetes | 6 | AZ-AKS-001 to 006 |
+| Post-quantum | 3 | AZ-PQC-001 to 003 |
 
 Every rule has a matching Azure CLI playbook in `playbooks/cli/`.