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.

Scanned Files

None

[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".