This is a documentation-first repository. It contains governance solution scaffolds, control mappings, and PowerShell scripts that operate on representative sample data. The scripts in this repository do not connect to live Microsoft 365 tenants and are not intended to process production secrets.

See docs/disclaimer.md and docs/documentation-vs-runnable-assets-guide.md for the full scope statement.

Security review is provided for the latest tagged release.

If you believe you have discovered a security issue in the documentation, scripts, or configuration templates in this repository, please report it privately rather than opening a public issue.

• Email: security@example.com
• Please include: the file path, the commit SHA, a description of the issue, and (where applicable) a redacted reproduction.

We aim to acknowledge reports within five business days.

Because this repository is documentation-first, it should not contain live credentials. To help meet that expectation:

• Contributors are expected to run a secret scan locally before opening a pull request. The CI workflow at .github/workflows/secret-scan.yml runs gitleaks on every pull request, every push to main, and on a weekly schedule.
• Operator action (not a code change): GitHub-native secret scanning and push protection are expected to be enabled at the organization or repository level. These settings are required to block credential pushes at the GitHub edge and cannot be enforced from within this repository.

Tagged releases (v*.*.*) are built by .github/workflows/release.yml. The workflow publishes the following artifacts and a corresponding build-provenance attestation for each one:

• sbom-python-docs.cdx.json — CycloneDX SBOM of Python documentation dependencies (requirements-docs.txt).
• sbom-python-project.cdx.json — CycloneDX SBOM derived from pyproject.toml (best-effort; may be omitted when no lockfile is installed).
• sbom-repo.cdx.json — CycloneDX SBOM of repository contents (generated by anchore/sbom-action).
• RELEASE-MANIFEST.txt — SHA-256 of every git-tracked file at the release commit (deterministic, sorted by path; produced by scripts/gen-release-manifest.py).

Attestations are signed via GitHub's OIDC-backed Sigstore instance using actions/attest-build-provenance. Downstream consumers can verify any artifact with the gh attestation verify command:

# Download an artifact from the release page, then:
gh attestation verify sbom-repo.cdx.json \
  --repo judeper/FSI-CopilotGov-Solutions

# Or pin the verification to the workflow that produced it:
gh attestation verify RELEASE-MANIFEST.txt \
  --repo judeper/FSI-CopilotGov-Solutions \
  --signer-workflow judeper/FSI-CopilotGov-Solutions/.github/workflows/release.yml

A successful verification confirms the artifact was produced by the release.yml workflow in this repository at the published tag. Verification does not validate the semantic accuracy of the SBOM contents or the governance posture of downstream tenants.

Operator action (not a code change): publishing release attestations requires the workflow to run with id-token: write and attestations: write permissions, and the repository / organization must allow GitHub Actions to create release artifacts (default for public repositories; private repositories may require enabling Sigstore-backed attestations under Settings → Actions → General).

This policy does not:

• Cover security of downstream tenants where these scaffolds are deployed.
• Provide a guarantee that scripts are free of defects.
• Replace your organization's vulnerability management or incident response program.