docs: add CODE_OF_CONDUCT and SECURITY for OpenSSF Silver badge

[TFT444]

Summary

Adds two documents required for the OpenSSF Best Practices Silver badge (currently at ~13%).

• CODE_OF_CONDUCT.md: Contributor Covenant v2.1. Covers the code_of_conduct Silver criterion.
• SECURITY.md: Vulnerability reporting process (private advisory, 48h acknowledgement, coordinated disclosure), response timeline, supported versions, and security scope. Covers vulnerability_report_process and vulnerability_response_process.

What this unblocks

After this merges, the badge owner (Vishnu) can log into bestpractices.dev and mark these plus all already-implemented criteria as Met:

Criterion	Evidence
code_of_conduct	CODE_OF_CONDUCT.md (this PR)
vulnerability_report_process	SECURITY.md (this PR)
vulnerability_response_process	SECURITY.md (this PR)
dco	DCO job in .github/workflows/ci.yml
dependency_monitoring	.github/dependabot.yml
automated_integration_testing	GitHub Actions CI
warnings_strict	Ruff strict config in pyproject.toml
coding_standards_enforced	Ruff lint job in ci.yml
test_statement_coverage80	--cov-fail-under=80 in CI test job
governance	GOVERNANCE.md
report_tracker	GitHub Issues

Marking those criteria alone should move silver progress from ~13% to ~75-80%.

No code changes

Documentation only. No scanner rules, API, or CI logic affected.

Closes part of #342. See also #199.

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

OpenSSF Scorecard

Package	Version	Score	Details
pip/multidict	6.9.1	🟢 6.6	Details Check Score Reason Code-Review ⚠️ 0 Found 1/30 approved changesets -- score normalized to 0 Binary-Artifacts 🟢 10 no binaries found in the repo Maintained 🟢 10 30 commit(s) and 24 issue activity found in the last 90 days -- score normalized to 10 Dangerous-Workflow 🟢 10 no dangerous workflow patterns detected Token-Permissions ⚠️ 0 detected GitHub workflow tokens with excessive permissions Pinned-Dependencies ⚠️ 0 dependency not pinned by hash detected -- score normalized to 0 CII-Best-Practices ⚠️ 0 no effort to earn an OpenSSF best practices badge detected Fuzzing 🟢 10 project is fuzzed License 🟢 10 license file detected Security-Policy 🟢 10 security policy file detected Packaging 🟢 10 packaging workflow detected SAST 🟢 10 SAST tool is run on all commits Branch-Protection 🟢 3 branch protection is not maximal on development and all release branches Signed-Releases 🟢 8 5 out of the last 5 releases have a total of 5 signed artifacts.
pip/werkzeug	3.1.9	Unknown	Unknown

Scanned Files

• requirements.txt

[TFT444]

@Vishnu2707 CI is all green on this one. Two docs only, no code changes.

After this merges, next step is for you to log into https://www.bestpractices.dev/en/projects/13618/silver and mark these criteria as Met:

• code_of_conduct - link to CODE_OF_CONDUCT.md
• vulnerability_report_process - link to SECURITY.md
• vulnerability_response_process - link to SECURITY.md
• dco - link to the DCO job in ci.yml
• dependency_monitoring - link to dependabot.yml
• automated_integration_testing - link to ci.yml
• warnings_strict - link to pyproject.toml ruff config
• coding_standards_enforced - link to the ruff lint job in ci.yml
• test_statement_coverage80 - link to the --cov-fail-under=80 line in ci.yml
• governance - link to GOVERNANCE.md
• report_tracker - link to GitHub Issues

That should push silver from ~13% to ~75-80% in one session. Can you review and approve this PR?

[ritiksah141]

Approving it as part of documentation only

[parthrohit22]

Thanks @TFT444. Getting the Silver criteria unblocked is worth doing. I checked this against what's already in the repo and against the repo settings, and I'm requesting changes on four points. The first two mean the policy wouldn't work as written.

1. This duplicates policy files that already exist

dev already has .github/SECURITY.md and .github/CODE_OF_CONDUCT.md. GitHub resolves the repository's Code of Conduct to the .github/ copy today (GET /repos/OWASP/openshield/community/profile returns .github/CODE_OF_CONDUCT.md). SUPPORT.md and CONTRIBUTING.md both send reporters to .github/SECURITY.md. Adding root-level copies leaves two diverging policies:

• Which file wins: the Security tab and the community profile keep showing the old .github/ versions.
• Where the badge evidence points: the bestpractices.dev evidence would link to the new root files.
• They already disagree: the supported versions (0.3.x vs "latest main") and the in-scope components are different.

Please update the .github/ files in place instead of adding new ones at the root.

2. The only reporting channel isn't enabled

Both new files route reports to https://github.com/OWASP/openshield/security/advisories/new. Private vulnerability reporting is off for the repo:

$ gh api repos/OWASP/openshield/private-vulnerability-reporting
{"enabled":false}

With it off, that link doesn't accept reports from outside collaborators. The existing .github/SECURITY.md isn't better: it says "you email the vulnerability privately" but gives no address. So as of today there is no working private channel. @Vishnu2707 needs to enable private vulnerability reporting (Settings → Code security) before this merges. A monitored fallback email in the policy would also help, because the badge criterion is about reporters actually reaching someone.

The Code of Conduct has the same problem: it routes conduct reports through a security advisory. That's the wrong channel even once it's enabled, because conduct reports shouldn't sit in the vulnerability tracker. Please give a named contact or email for enforcement. OWASP's own Code of Conduct and reporting route apply to OWASP projects, so linking to that is probably the simplest answer.

3. The scope section understates the attack surface

"OpenShield is a read-only Azure security posture scanner … it does not modify, remediate, or deploy anything" isn't accurate for this repo:

• playbooks/cli/ ships remediation scripts that change Azure resources.
• There is a REST API with JWT/OIDC auth and role checks.
• The AI endpoints process untrusted finding text (#359).
• sentinel/ signs and uploads data to Log Analytics.

The new policy also drops the in-scope list that the current .github/SECURITY.md has (API authentication and authorisation, JWT handling, Sentinel HMAC). A reporter reading the new version could reasonably conclude that an auth bypass in api/ is out of scope. Please keep an explicit in-scope list covering api/, scanner/, playbooks/, sentinel/, the dashboard and the website CMS.

Related: "does not store, transmit, or log credentials beyond the running process" is an absolute claim that nobody has audited, and the Sentinel shared key and the GitHub App private key make it hard to stand behind. Scope it to what is verified, or drop it.

4. "Branch protection: required reviews and passing CI before merge" isn't true yet

#344 declares the rulesets, but an admin still has to apply them. Right now:

$ gh api repos/OWASP/openshield/rulesets
[]

Please drop that row or reword it until the rulesets are applied. A security policy that overstates the controls is worse than one that leaves them out.

Minor

• A 48-hour acknowledgement is the same promise the current policy makes. It's fine if someone is actually on rotation; the OpenSSF criterion only requires a response within 14 days, so a target you can keep is better than one you'll miss.
• Point credits at the existing SECURITY_ACKNOWLEDGEMENTS.md rather than "release notes".

[TFT444]

Fixed all four blockers from your review:

1. Root-level files removed — deleted root SECURITY.md and CODE_OF_CONDUCT.md. GitHub resolves these to .github/ copies; updated those in place instead so the Security tab and community profile both show the correct content.

2. PVR not-yet-enabled note — .github/SECURITY.md now includes a note that private vulnerability reporting needs to be enabled by an org owner (Settings > Code security) before the advisory link works, with vishnu.ajith@owasp.org as the fallback contact.

3. Scope section corrected — removed the false 'read-only scanner' claim. The new scope table accurately lists api/ (JWT/OIDC auth, RBAC), playbooks/cli/ (modifies Azure resources), sentinel/ (HMAC signing + upload), and the AI endpoints (process untrusted text). The scanner/ read-only nature is clarified separately.

4. False branch protection claim removed — the row claiming 'Required reviews and passing CI before merge' is gone since rulesets is still empty.

CODE_OF_CONDUCT.md is also upgraded from the 5-line stub to full Contributor Covenant v2.1, with the enforcement contact fixed to use GitHub DM rather than the security advisory channel (wrong channel for conduct reports).

Please re-review when you get a chance @parthrohit22

[TFT444]

@parthrohit22 all requested changes are addressed: root-level policy files removed (only .github/ versions remain), scope section updated to include playbooks/cli/, REST API, AI endpoints and sentinel/, branch protection claim removed, and the Code of Conduct enforcement section now names Vishnu Ajith with a contact email and links to OWASP's reporting route. Could you re-review when you get a chance? Thanks.

[parthrohit22]

Thanks for addressing the previous feedback. I still see two gaps in the security reporting policy that should be resolved before merge:

[parthrohit22]

The in-scope list still omits the React dashboard (frontend/) and project website (website/), both of which are code surfaces in this repository. My earlier review explicitly asked for the dashboard and website to be covered. Please list them with relevant examples, or clearly state their intended scope so reporters know whether vulnerabilities there are accepted.

[TFT444]

Fixed in ed61c25 — frontend/ (React dashboard: XSS, CSRF, auth state handling) and website/ (Astro site: XSS, content injection, dependency vulnerabilities) are now listed in the in-scope table.

[parthrohit22]

I verified that GitHub private vulnerability reporting is currently disabled for this repository. Since the policy's fallback email is the only working route for outside reporters, please confirm that this address is monitored for security reports (and that the owner accepts reports there), or enable private vulnerability reporting before publishing this process. Otherwise a reporter may still have no reliable private channel.

[TFT444]

The fallback email (vishnu.ajith@owasp.org) is already documented in the policy as the working route while PVR is disabled. Confirming that the address is actively monitored and enabling PVR are admin actions that require @Vishnu2707 — those are not code changes we can make in this PR. The file does everything it can on our side.

[TFT444]

@parthrohit22 both inline comments addressed: frontend/ and website/ are now in the in-scope table (commit ed61c25), and the PVR thread has a reply explaining that the fallback email is documented and enabling PVR requires @Vishnu2707. Could you re-review when you get a chance? Thanks.

[parthrohit22]

Thanks @TFT444. The structural fixes are all verified: in-place .github/ edits, the corrected scope table including frontend/ and website/, the branch-protection row removed, the CoC enforcement contact, and a faithful Contributor Covenant 2.1 text. Two corrections on my side: the current SECURITY.md did already list vishnu.ajith@owasp.org (since #64), and required reviews are enforced on dev; it's required status checks that are not.
Three small things left in the files:
1. SECURITY.md:95: "DCO sign-off — Enforced on every commit" isn't accurate. No status check on dev is required (I checked isRequired on this PR's checks), so a PR with a failing DCO check can still be merged. Suggest "DCO sign-off check runs on every pull request".
2. The new in-scope table drops compliance/ (mapping data integrity), which the current policy lists. Since #310 these mappings drive compliance reports, so please add it back.
3. CODE_OF_CONDUCT.md:62: "open a private discussion on this repository": GitHub Discussions are always public, so that channel would expose the reporter. Please remove that clause.
@Vishnu2707: two admin items, not blockers for the author. Please enable private vulnerability reporting (Settings → Code security), and confirm your Owasp mail address is monitored for security reports. Until private reporting is on, the email should read as the primary channel.
Happy to approve once 1–3 are in.

[TFT444]

@parthrohit22 All three concerns from your last review are now fixed: DCO wording corrected, compliance/ added to the in-scope table, and the public-discussions reference removed from CODE_OF_CONDUCT.md. Please re-review when you get a chance.

[TFT444]

@ritiksah141 @parthrohit22 could you please re-review the latest head (6223a09)?

Security-policy scope and reporting wording are updated. Confirmation of an operational security-reporting channel remains a maintainer gate.

The fixes are pushed and all checks are passing on this head (the deployment skip is expected). Please review the updated code and tests, and update your review decision or resolve the relevant conversations when satisfied.