oss-policy-kit 3.0.0

Open source starter kit for adopting OSS security baselines via policy packs, templates, evidence, and remediation.

OSS Security Policy as Code Starter Kit

Evaluate clone-visible OSS repository governance plus GitHub Actions, Azure Pipelines, and AWS CodeBuild/CodePipeline signals from a local clone. Platform truth outside the repository still requires evidence or manual review.

This project is intentionally small and explicit about trust boundaries. GitHub support is the most mature path today; Azure and AWS support are clone-based and evidence-driven rather than live platform verification.

Quick Links

• What This Kit Does
• Quickstart
• CI/CD Integration
• Validation Walkthrough
• CLI Usage
• How To Interpret Results
• Adoption Paths
• Documentation
• Maintainer Self-Check

At A Glance

Area	What you get
Input	A local repository clone
Output	evaluation-report.json and evaluation-report.md
Core scope	Clone-visible governance and GitHub/Azure/AWS CI/CD signals
Profiles	github-*, azure-*, and aws-* ladders (level-1..3, release-hardening-*) via profiles or --show-profiles
Exceptions	Waiver registry support with owner, reason, and expiry
Examples	Hardened and vulnerable sample repositories
Packaging	Python package with CLI and bundled policy data
Positioning	Evidence and signals, not certification

Why This Exists

Many OSS baselines mix three very different things:

• controls that can be checked from a clone
• controls that require platform context
• controls that still require human judgment

This kit keeps those categories separate.

Instead of collapsing everything into a misleading score, it gives you:

• versioned controls
• staged profiles
• explicit result states
• local JSON and Markdown reports
• waiver support
• reproducible examples and templates

What This Kit Does

The starter kit helps you assess whether a repository shows a practical OSS baseline in files and workflows that are observable locally.

It focuses on:

• SECURITY.md, CONTRIBUTING.md, LICENSE, CODEOWNERS, changelog presence
• clone-visible GitHub Actions, Azure Pipelines, and AWS build/pipeline structure and hygiene signals
• report generation for humans and pipelines
• policy lifecycle markers such as stable, experimental, and deprecated
• additive local evidence such as waivers and optional platform evidence files

What This Kit Does Not Do

• It is not a universal application security scanner.
• It is not an OSPS certification engine.
• It is not a compliance guarantee.
• It is not a substitute for threat modeling, secure code review, pentesting, or GitHub settings review.
• It does not replace dedicated SAST, DAST, or deep SCA products; it complements them by checking governance and clone-visible CI hygiene.
• Similar-looking results across unrelated repositories are normal when those repos lack visible governance and CI signals in the clone; that reflects scope, not a broken engine.

Treat outputs as local evidence and prioritization signals, not as "pass means safe".

Who It Is For

• OSS maintainers who want a practical baseline
• AppSec and DevSecOps engineers supporting open source programs
• teams building a demonstrable policy-as-code starter project

Quickstart

Requires Python 3.12+.

How to install (official channels)

Pick one path; they are listed in priority order for most users.

1. From a GitHub Release wheel (recommended for consumers)
   Download oss_policy_kit-*.whl from the Releases page for the version you want, then install into a clean virtual environment:

   python -m pip install /path/to/oss_policy_kit-1.0.2-py3-none-any.whl
   

   On Windows PowerShell, after python -m build, a typical install from the repo root is:

   python -m pip install (Get-ChildItem dist\oss_policy_kit-*.whl | Select-Object -First 1 -ExpandProperty FullName)
   

   Prefer python -m oss_policy_kit for CLI entry on Windows so you do not depend on Scripts\ being on PATH.

2. From source (contributors and local development)
   Clone the repository and use an editable install with dev tools:

   python -m pip install -e ".[dev]"
   

3. PyPI
   The package name oss-policy-kit is declared in pyproject.toml for future use, but PyPI distribution is not wired or guaranteed in this repository revision. Do not assume pip install oss-policy-kit==<version> until maintainers document a published index entry and release process. Until then, use source or GitHub Release wheels only.

Install From The Repository (development)

python -m pip install -e ".[dev]"

Run The Built-In Examples

python -m oss_policy_kit evaluate --target ./examples/vulnerable-repo --profile github-level-1 --output-dir ./out/vulnerable
python -m oss_policy_kit evaluate --target ./examples/hardened-repo --profile github-level-1 --output-dir ./out/hardened

Read The Outputs

• evaluation-report.md for human review
• evaluation-report.json for tooling, CI, and regression checks

What Success Usually Looks Like

• examples/hardened-repo on github-level-1: pass: 16
• examples/vulnerable-repo on github-level-1: multiple fail
• this repository on github-level-1: use the current self-check report as the source of truth; do not assume all-pass on every revision
• github-release-hardening-1: typically pass plus one branch-protection result that remains manual-review-required or self-attested, depending on local evidence

CI/CD Integration

Starter workflows live under templates/workflows/:

• github-oss-policy-check.yml — baseline evaluate against github-level-1, fail the job when any control is fail.
• github-oss-policy-check-with-waivers.yml — same as above but passes --waivers ./waivers/waivers.yaml.
• github-oss-policy-check-level-2.yml — stricter github-level-2 profile when your GitHub Actions maturity justifies it.

Typical CI command:

python -m oss_policy_kit evaluate --target . --profile github-level-1 --fail-on fail --output-dir ./oss-policy-reports

Interpret exit codes in pipelines: 0 means evaluation finished and the --fail-on threshold was not violated; 1 means the gate tripped (fail counts, or manual-review-required when using --fail-on degraded). 2 is usage or load errors—treat as a pipeline configuration problem, not a policy failure.

Artifacts in the workflow templates upload ./oss-policy-reports/ so you retain JSON and Markdown evidence even when the gate fails early.

GitHub Releases for this kit include wheels, sdist, and an SBOM (sbom.cyclonedx.json) produced in the publish workflow.

Validation Walkthrough

This section is the fastest way to understand how the kit is meant to be used in practice. It walks through the command flow in the same order a maintainer or AppSec engineer would normally follow:

1. learn the CLI surface
2. choose the right profile
3. run a quick demo or self-check
4. compare expected good and bad repository shapes
5. turn the same evaluation into a CI gate

Treat these artifacts as operational evidence. They show that the kit runs, reports clearly, and differentiates repository posture. They do not claim that a pass result is equivalent to universal security assurance.

Command Flow At A Glance

Step	Command or artifact	Use it when
Understand the CLI	python -m oss_policy_kit --help	You want to see the supported commands, flags, and exit codes before wiring the tool into scripts or CI.
Discover profiles	python -m oss_policy_kit profiles or python -m oss_policy_kit --show-profiles	You need to choose the right platform and strictness level before running an evaluation.
Run the short demo	scripts/demo-video.ps1	You want a fast visual proof that hardened and vulnerable repositories produce different outcomes.
Self-check the current repo	python -m oss_policy_kit evaluate --target . --profile github-level-1 --output-dir ./out/selfcheck	You want to validate the current repository revision using the same kit it ships.
Compare fixtures	python -m oss_policy_kit evaluate --target ./examples/...	You want a stable passing fixture and a stable failing fixture for demos, tests, or onboarding.
Gate CI	python -m oss_policy_kit evaluate --target . --profile github-level-1 --output-dir ./out/selfcheck-ci --fail-on fail	You want reports written first and the pipeline blocked only when the chosen threshold is violated.

1. Learn The CLI Surface

Start with the help output. This is the right command to use when you are integrating the tool for the first time, because it shows:

• the preferred evaluate entrypoint
• compatibility invocation forms
• output options such as --summary-only and --format
• the exit-code contract used by local scripts and CI

python -m oss_policy_kit --help

2. Discover And Choose A Profile

Before evaluating a repository, choose the profile that matches the platform and the desired assurance level. That is the context for the two profile-discovery commands:

• python -m oss_policy_kit --show-profiles prints the bundled profile table
• python -m oss_policy_kit profiles prints the same bundled profile table

Use level-1 when you are starting with the baseline and want honest clone-only checks. Move to higher levels or release-hardening-* profiles when you want stricter controls and are ready to provide supporting evidence for release posture.

python -m oss_policy_kit --show-profiles
python -m oss_policy_kit profiles

3. Run The 10-Second Demo

When you need a fast demonstration for a README, presentation, or quick sanity check, the repository includes a short scripted demo in scripts/demo-video.ps1. It runs the same evaluate command twice against the same github-level-1 profile, changing only the target repository so the behavioral contrast is obvious.

The first command in the screen targets ./examples/hardened-repo and uses --summary-only to collapse the result to status counts instead of printing file paths and report locations. summary: pass=16 means all 16 controls in that profile passed for the hardened fixture.

The second command targets ./examples/vulnerable-repo with the same profile and the same summary mode. pass=2 | fail=13 | self-attested=1 means the kit found only two passing controls, thirteen direct failures, and one control that depends on self-attested evidence rather than repository proof. controls: 16 in both blocks confirms that the same policy set was evaluated in both cases, so the difference comes from repository posture, not from a different rule set.

Use this screen when you want the fastest possible explanation of what the tool does in practice: it compares a stronger repository and a weaker repository under the same baseline and shows that the output changes in a meaningful, deterministic way.

4. Validate The Package And The Current Repository

After the CLI and profiles are clear, the next step is to validate that the package itself is healthy and that the current repository revision can evaluate cleanly.

Run the automated test suite when you want regression confidence before changing code, policy data, or templates:

python -m pytest -q

The passing test run below is evidence that the implementation is stable at the code level, not just at the documentation level.

Then run a maintainer self-check when you want to know whether the repository itself satisfies the chosen baseline in its current revision:

python -m oss_policy_kit evaluate --target . --profile github-level-1 --output-dir ./out/selfcheck

This is the command to use when validating the repository before release, before documentation updates, or after changing workflows and governance files. The screenshot below shows the current repository producing an all-pass result for github-level-1.

5. Compare Known-Good And Known-Bad Fixtures

The bundled example repositories are the clearest way to understand what the tool is checking and why those checks matter.

Use the hardened example when you want to show the target baseline outcome:

python -m oss_policy_kit evaluate --target ./examples/hardened-repo --profile github-level-1 --output-dir ./out/hardened

This repository includes the expected governance files and CI signals, so it is the reference fixture for a strong github-level-1 result.

Use the vulnerable example when you want to prove that the kit is not a cosmetic report generator and that obvious repository weaknesses really do surface as non-pass states:

python -m oss_policy_kit evaluate --target ./examples/vulnerable-repo --profile github-level-1 --output-dir ./out/vulnerable

This is the right fixture for onboarding, demos, and CI-gate demonstrations because it shows missing governance artifacts, weak workflow patterns, and other expected gaps as actionable failures.

6. Read The Controls Table And Detail Blocks

After you see a fixture pass or fail at the summary level, the next step is to inspect the generated Markdown report and understand why each control resolved that way.

Use the vulnerable fixture for this walkthrough because it produces a mix of governance, CI/CD, release, and supply-chain findings:

python -m oss_policy_kit evaluate --target ./examples/vulnerable-repo --profile github-level-1 --output-dir ./out/vulnerable

Open ./out/vulnerable/evaluation-report.md and scroll past the summary sections. The ## Controls table is the compact triage view: one row per control, with the control id, category, lifecycle, status, confidence, short reason, remediation hint, and waiver column.

That table answers the first-level questions quickly: what failed, how confident the kit is, and what should be fixed next. In this example, the governance controls fail because the repository is missing SECURITY.md, CONTRIBUTING.md, CODEOWNERS, and LICENSE, while CI-WF-005 passes because a workflow file is present. The same table also shows why GOV-WAIV-014 can read as not-evaluated when no versioned in-repo waiver file is present: a CLI waiver file is not the same thing as a versioned in-repo waiver policy.

When you need the full reasoning behind one result, keep scrolling into ## Detail. Each control expands into a dedicated block with status, lifecycle, confidence, reason, remediation, and evidence when the evaluator found a concrete file or signal.

That detailed view is what makes the report actionable. A failing control explains exactly what is missing, while a passing control explains which signal satisfied the rule. In this example, governance controls fail because required repository files are absent, and CI-WF-005 passes because the evaluator detected at least one GitHub Actions workflow. This is the section to use when you are deciding what to remediate first or when you need to justify a result to someone else reviewing the repository.

7. Turn Evaluation Into A CI Gate

Once the report content makes sense locally, the same evaluation can be used as a pipeline gate. The key flag is --fail-on, which turns result thresholds into exit-code policy:

python -m oss_policy_kit evaluate --target . --profile github-level-1 --output-dir ./out/selfcheck-ci --fail-on fail

Use this mode when you want the job to:

1. complete evaluation
2. write evaluation-report.json and evaluation-report.md
3. fail the CI step only after the evidence is available for review

That behavior matters. A blocked pipeline should still leave behind actionable evidence. The screenshot below illustrates that exact pattern: the reports were written first, and the step ended with exit code 1 because the selected threshold was violated.

CLI Usage

Public Contract

The supported CLI forms are:

• preferred: python -m oss_policy_kit evaluate ...
• compatible: python -m oss_policy_kit --target ./repo --profile ...
• also supported: python -m oss_policy_kit ./repo --profile ...

The explicit evaluate subcommand is the clearest form and should be preferred in docs, scripts, and examples.

Day-to-day usage

1. First run: install the package, then python -m oss_policy_kit profiles (or --show-profiles) to pick a ladder, and python -m oss_policy_kit recommend-profile --target . for a quick hint.
2. Local maintainer loop: python -m oss_policy_kit evaluate --target . --profile github-level-1 --output-dir ./out/latest before tagging or opening a release PR; open evaluation-report.md for the narrative view.
3. Multi-app / monorepo: python -m oss_policy_kit evaluate-many --target-root ./apps --profiles github-level-1 --output-dir ./out/batch — read evaluation-batch.md first (consolidated totals, repeated gaps, relative paths to per-repo reports).
4. Waivers: keep versioned waivers in-repo for GOV-WAIV-014; use --waivers path.yaml only for temporary or CI-local exceptions and treat them as explicitly out-of-band from versioned policy.
5. Release-hardening + evidence: run scaffold-evidence once, fill .oss-policy-kit/evidence/*.json, then evaluate with github-release-hardening-* (or Azure/AWS equivalents). Re-run scaffold without --force to preserve hand-edited JSON; use --force only when you intend to replace templates.
6. Interpreting scope: read What This Kit Does / What This Kit Does Not Do when results look similar across apps — the kit measures clone-visible posture, not application logic flaws.

Profile Discovery

Use either of these:

• python -m oss_policy_kit profiles
• python -m oss_policy_kit --show-profiles

Both commands list the bundled ladders with platform, level, control count, and whether the profile stays clone-only or extends into release-hardening/evidence expectations. Listing goes to stdout (errors stay on stderr). Machine-readable catalog:

python -m oss_policy_kit profiles --format json

Heuristic profile suggestion from repository layout:

python -m oss_policy_kit recommend-profile --target ./examples/hardened-repo
python -m oss_policy_kit recommend-profile --target . --format json

Batch / Monorepo

Evaluate each immediate child directory of a root folder against one or more profiles (paths with spaces are supported via normal shell quoting):

python -m oss_policy_kit evaluate-many --target-root ./path/to/apps --profiles github-level-1 --output-dir ./out/batch

This writes per-target reports under ./out/batch/<child-name>/<profile-id>/ plus consolidated evaluation-batch.json and evaluation-batch.md.

Evidence Scaffolding

Generate schema-shaped starter files under .oss-policy-kit/evidence/:

python -m oss_policy_kit scaffold-evidence --target . --platform github

By default, existing files are not overwritten (stdout prints created / skipped / overwritten). Use --force only when you want to replace templates you have already edited.

Replace placeholders, then re-run evaluate with a release-hardening-* profile. Evidence remains self-attested (maintainer-supplied), not platform-verified.

Common Examples

Subcommand with --target:

python -m oss_policy_kit evaluate --target ./examples/hardened-repo --profile github-level-1 --output-dir ./out/hardened

Subcommand with positional target:

python -m oss_policy_kit evaluate ./examples/hardened-repo --profile github-level-1 --output-dir ./out/hardened

Top-level compatibility form:

python -m oss_policy_kit --target ./examples/hardened-repo --profile github-level-1 --output-dir ./out/hardened-root

Optional Inputs

Unix-like shells:

python -m oss_policy_kit evaluate --target ./path/to/repo \
  --profile github-level-1 \
  --output-dir ./out \
  --waivers ./waivers/waivers.example.yaml \
  --scorecard-json ./path/to/scorecard.json

Windows PowerShell:

python -m oss_policy_kit evaluate --target .\path\to\repo --profile github-level-1 --output-dir .\out --waivers .\waivers\waivers.example.yaml

Pipeline-Friendly Output

For compact stdout suitable for CI parsing:

python -m oss_policy_kit evaluate --target . --profile github-level-1 --output-dir ./out --summary-only --format json

The JSON summary includes:

• ordered summary_by_status
• controls_total
• operational_warnings_count

The human --summary-only mode prints a short, action-oriented recap (counts, top gaps, suggested next step) while keeping this JSON contract stable.

Waivers: versioned in repo vs --waivers

• --waivers: external YAML loaded for this run only; may set specific controls to waived. The report states the absolute path under external_waiver_path.
• GOV-WAIV-014: checks for a versioned waiver policy file inside the clone (for example waivers/waivers.yaml). Using --waivers does not satisfy that control by design; the Markdown report explains both mechanisms side by side.

Exit Codes

After a successful evaluation:

Code	Meaning
0	Completed and --fail-on threshold was not violated
1	Completed and --fail-on threshold was violated
2	Invalid usage, missing paths, or other user-correctable errors
3	Unexpected internal error

Windows Note

pyproject.toml exposes the oss-policy-kit console script, but on Windows the Scripts directory is not always on PATH.

• canonical invocation: python -m oss_policy_kit
• if you prefer the console script, use an activated virtual environment or ensure the Scripts directory is on PATH

Profiles

Bundled profiles are easier to inspect from the CLI than from a static README table:

python -m oss_policy_kit profiles
python -m oss_policy_kit --show-profiles

Profile families shipped in this build:

Family	Levels	Purpose
github-*	level-1..3, release-hardening*	Most mature path; GitHub workflow posture plus optional platform evidence
azure-*	level-1..3, release-hardening-1..3	Azure Repos / Azure Pipelines clone-based checks plus optional evidence
aws-*	level-1..3, release-hardening-1..3	AWS CodeBuild / CodePipeline clone-based checks plus optional evidence

Bundled policy data lives in:

• src/oss_policy_kit/data/controls/catalog.yaml
• src/oss_policy_kit/data/profiles/*/profile.yaml

How To Interpret Results

Each control resolves to one of these states:

Status	Meaning
pass	A positive local signal was observed
fail	A required signal was missing or a high-signal problem was detected
manual-review-required	The control cannot be safely confirmed from a clone alone; review manually
self-attested	Local evidence exists, but trust still depends on maintainer honesty or platform confirmation
not-observable	The control exists conceptually but is not locally observable
not-applicable	The control does not apply to the evaluated repository shape
waived	A documented exception overrode a non-pass outcome

Reports include:

• evidence sources
• confidence
• reason
• remediation text
• waiver metadata when applicable

What The Kit Can Observe Locally

• tracked governance files
• workflow YAML structure and static content
• optional local evidence files
• optional waiver registry
• optional Scorecard JSON used as supplemental evidence

What The Kit Cannot Prove From A Clone Alone

• live GitHub branch protection or rulesets
• organization-level policies outside the clone
• runtime behavior of reusable workflows or complex expressions
• compliance or certification against a formal framework

all-pass On github-level-1 vs github-release-hardening-1

• github-level-1 has 16 controls. all-pass means sixteen pass outcomes for that profile.
• github-release-hardening-1 adds PLAT-BRPROT-015. Branch protection is enforced on GitHub, not in the clone, so a strong local repository can still end with pass plus manual-review-required or self-attested for that control.

That behavior is intentional. It is the tool being honest, not a defect.

GitHub Profile Ladder

• github-level-1: pragmatic baseline with clone-visible governance and CI hygiene.
• github-level-2: adds stricter workflow hardening (GH-WF-018 to GH-REL-021).
• github-level-3: adds strict deployment identity and provenance expectations (GH-DEPLOY-022, GH-PROV-023).
• github-release-hardening-1: level-1 + branch-protection evidence/manual-review.
• github-release-hardening-2: level-2 + platform evidence controls (GH-PLAT-024..026).
• github-release-hardening-3: level-3 + platform evidence controls (PLAT-BRPROT-015, GH-PLAT-024..026).

When self-attested Is Normal

Examples:

• GOV-WAIV-014 as not-evaluated when no versioned in-repo waiver file is present (optional governance)
• PLAT-BRPROT-015 when local evidence JSON exists but platform truth still needs confirmation in GitHub

Adoption Paths

Path	What to copy	Expected github-level-1 outcome
Minimal	Governance docs only, or CI without SBOM/security coverage	Useful gap analysis, but often fewer than 16 pass
Recommended	templates/workflows/ci.yml, templates/workflows/security.yml, templates/waivers/waivers.yaml, plus docs/templates as needed	Target pass: 16 for a standard Python src/ layout
Hardening	Recommended path plus optional .oss-policy-kit/evidence/branch-protection.json and the github-release-hardening-1 profile	Expect strong results plus a platform-related non-pass state when proof remains local-only

Recommended entry points:

• docs/adoption-guide.md
• docs/recommended-adoption-playbook.md

Applicability

This kit evaluates OSS repository posture and clone-visible CI/CD hygiene from a local clone.

It is a good fit for repositories that want:

• explicit governance
• review ownership
• CI hygiene
• release evidence

It is not a full application security assessment.

A generic internal app, lab, or service without SECURITY.md, CONTRIBUTING.md, CODEOWNERS, GitHub workflows, or changelog artifacts will often show many failures by design. That means OSS-style repository evidence is missing. It does not mean the runtime system is comprehensively insecure.

Use the results to improve:

• repository hygiene
• PR and CI posture
• evidence collection
• release preparation

Do not use the results as a substitute for:

• threat modeling
• secure code review
• platform configuration review
• cloud or infrastructure assessment
• penetration testing

Automation Limits

Local evaluation can inspect only what exists in the working tree. It cannot reliably prove:

• GitHub branch protection or rulesets
• GitHub Advanced Security feature enablement
• organization-level policies outside the clone
• runtime behavior of reusable workflows, composite actions, or expression-heavy logic

For those areas, the kit intentionally uses:

• manual-review-required
• optional self-attested evidence
• optional supplemental context such as Scorecard JSON

Examples And Fixtures

• examples/hardened-repo demonstrates a strong baseline and should pass github-level-1
• examples/vulnerable-repo demonstrates obvious gaps and is useful for testing CI gates
• tests/fixtures/repositories/ contains edge-case repository shapes used by the test suite

Repository Layout

src/oss_policy_kit/        Python package (domain, application, adapters, infrastructure, CLI)
src/oss_policy_kit/data/   Bundled policy data (catalog and profiles)
templates/                 Governance docs, workflow examples, waiver template, ruleset examples
examples/                  Vulnerable and hardened sample repositories
tests/fixtures/            Static fixtures, including repository-shaped test inputs
waivers/                   Example and active waiver registries
reports/schema/            Public JSON Schema for evaluation output
docs/                      Supporting technical documentation
gitpage/                   Optional Vite/React site for GitHub Pages (not part of the Python package)

Documentation

• docs/README.md - documentation hub
• Project site - public product site
• docs/adoption-guide.md - baseline selection and expected outcomes
• docs/recommended-adoption-playbook.md - copy/paste adoption path
• docs/architecture.md - package boundaries, trust model, and evidence semantics
• docs/packaging-and-release.md - install, build, and distribution guidance
• docs/release-readiness.md - release gate and public launch checks

Maintainer Self-Check

Run the kit against this repository:

python -m oss_policy_kit evaluate --target . --profile github-level-1 --output-dir ./out/selfcheck

Treat the generated self-check report as authoritative for the current revision. This repository aims to stay close to github-level-1, but workflow drift and evidence choices can change the exact summary.

Evaluation Report schema_version

JSON reports default to schema_version with the suffix reports/0.2 (with live_collection and per-control evidence_collection_method). Use evaluate --report-json-contract 0.1 to emit the legacy reports/0.1 shape. The suffix identifies the report contract under reports/schema/; it is not the Python package version.

Release Line And Semver

The 1.x line is the stable major line of the project.

Semver intent:

• MAJOR for incompatible public changes
• MINOR for backward-compatible additions
• PATCH for fixes, hardening, documentation, templates, and operational improvements

For the exact released version, see:

• CHANGELOG.md
• GitHub Releases

Project Status

This project is published, maintained, and intentionally scoped.

It prioritizes:

• clarity over hype
• evidence over vague scoring
• explicit limits over fake assurance

Planned evolution stays conservative and is reflected through released changes and public documentation rather than a separate roadmap file.

Contributing

See CONTRIBUTING.md.

Security

See SECURITY.md.

License

Apache-2.0. See LICENSE and NOTICE.