windlasstech · yunseo-kim · Jun 14, 2026 · Jun 13, 2026 · Jun 13, 2026 · Jun 13, 2026
@@ -68,191 +68,102 @@ Please do not:
 - Degrade service availability
 - Social engineer, spam, or perform destructive testing
 
+## Security Monitoring
+
+### Audit Logging
+
+- All workflow runs are logged via GitHub's audit log
+- Access to secrets is logged
+- Deployment activity is tracked
+
+### Vulnerability Scanning
+
+- Dependabot alerts are enabled on all repositories
+- Code scanning with CodeQL runs on all PRs
+- OSV Scanner runs on PRs and scheduled full scans
+- Secret scanning prevents credential leakage
+
+### OpenSSF Scorecard
+
+This organization uses [OpenSSF Scorecard](https://securityscorecards.dev/) to continuously monitor security posture:
+
+- Binary artifacts
+- Branch protection
+- Code review
+- Dependency update tool
+- Fuzzing
+- License
+- Maintained
+- Pinned dependencies
+- SAST
+- Security policy
+- Signed releases
+- Token permissions
+- Vulnerabilities
+
 ## Supply Chain Integrity
 
 This organization follows the [SLSA (Supply-chain Levels for Software Artifacts)](https://slsa.dev/) framework to ensure software supply chain security. Detailed implementation guidance is available in the companion documents linked below.
 
 ### At a Glance
 
-- Build L1/L2 required; Build L3 target
-- Source L1/L2 required; Source L3 target
+- Build L1/L2 required; Build L3+ target wherever feasible
+- Source L1/L2 required; Source L3 controls followed wherever feasible
 - Source L4 not achievable in a 1-person organization
 - SHA-pinned workflows, hardened runners, least-privilege permissions
 - Lockfiles committed, dependency review, OSV scanning
 - Signed commits, protected branches, OIDC, release integrity
+- Build provenance and SBOM attestations for released artifacts
+- Linked artifacts metadata for registry-published release artifacts
 
 ### Detailed Requirements
 
 | Topic                     | Companion document                                                                         |
 | :------------------------ | :----------------------------------------------------------------------------------------- |
 | SLSA compliance framework | [docs/security/slsa-compliance-framework.md](./docs/security/slsa-compliance-framework.md) |
 | Workflow hardening        | [docs/security/workflow-hardening.md](./docs/security/workflow-hardening.md)               |
+| Artifact attestations     | [docs/security/artifact-attestations.md](./docs/security/artifact-attestations.md)         |
 | Dependency security       | [docs/security/dependency-security.md](./docs/security/dependency-security.md)             |
 
-### Source Integrity
-
-#### Commit Signing
-
-All commits to protected branches must be cryptographically signed:
-
-- **GPG signing** — Traditional approach using GPG keys
-- **SSH signing** — Alternative to GPG using SSH keys
-- **Sigstore gitsign** — Keyless signing linking to OIDC identity (recommended)
+### Source and Workflow Integrity
 
-#### Branch Protection
+Source and workflow controls are implemented through signed commits, protected branches, SHA-pinned actions, hardened runners, least-privilege workflow permissions, and OIDC-based cloud authentication.
 
-All repositories must enforce:
-
-- Require signed commits
-- Require pull request reviews (minimum 1 reviewer)
-- Require status checks to pass before merging
-- Require linear history (no merge commits)
-- Include administrators in restrictions
-- Restrict force pushes
-
-### OIDC and Cloud Authentication
-
-Use OpenID Connect (OIDC) for authentication to cloud providers instead of long-lived credentials stored as secrets.
-
-#### Supported Providers
-
-- AWS — `aws-actions/configure-aws-credentials`
-- Azure — `azure/login`
-- Google Cloud — `google-github-actions/auth`
-
-#### AWS OIDC Example
-
-```yaml
-permissions:
-  id-token: write
-  contents: read
-
-jobs:
-  deploy:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
-
-      - name: Configure AWS credentials
-        uses: aws-actions/configure-aws-credentials@e3dd6a429c905ace6919b0a7664b96b2b5dc3c81 # v4.0.2
-        with:
-          role-to-assume: arn:aws:iam::123456789012:role/github-deploy-role
-          aws-region: us-east-1
-
-      - name: Deploy
-        run: aws s3 sync ./dist s3://my-bucket/
-```
+- Source track requirements, branch protection controls, and commit signing expectations are documented in [SLSA Compliance Framework: SLSA Source Track Requirements](./docs/security/slsa-compliance-framework.md#slsa-source-track-requirements).
+- GitHub Actions hardening, permission patterns, and OIDC provider examples are documented in [Workflow Hardening](./docs/security/workflow-hardening.md).
 
 ### Release Integrity
 
 - **GPG-signed tags** — All release tags are GPG-signed annotated tags
 - **GPG-signed commits** — All commits on `main` must be GPG-signed (enforced by repository rulesets)
 - **Linear history** — Squash-merge-only policy prevents history rewriting; force-push to `main` is blocked
 - **CI gate** — All required status checks must pass before any merge to `main`
-- **Artifact attestations** — All released artifacts must include signed attestations
-
-## Verifying Artifacts
-
-Consumers can verify the authenticity and provenance of artifacts from this organization using the GitHub CLI:
-
-### Install GitHub CLI
-
-```bash
-# macOS
-brew install gh
-
-# Ubuntu/Debian
-sudo apt install gh
-
-# Or download from https://cli.github.com/
-```
-
-### Verify Binary Attestations
-
-```bash
-# Verify a downloaded binary
-gh attestation verify ./my-artifact -R windlass-tech/my-repo
-
-# Verify with specific workflow
-gh attestation verify ./my-artifact \
-  -R windlass-tech/my-repo \
-  --signer-workflow windlass-tech/my-repo/.github/workflows/release.yml
-```
-
-### Verify Container Image Attestations
-
-```bash
-# Verify a container image
-gh attestation verify oci://ghcr.io/windlass-tech/my-image:latest \
-  -R windlass-tech/my-repo
-
-# Verify by digest (recommended)
-gh attestation verify oci://ghcr.io/windlass-tech/my-image@sha256:abc123... \
-  -R windlass-tech/my-repo
-```
+- **SLSA Build L3+ provenance** — Released artifacts should use SLSA GitHub Generator builders or reusable workflow based attestation to produce hardened Build L3+ provenance wherever feasible
+- **Baseline build provenance attestations** — If an L3+ path is not available for a repository yet, released artifacts that consumers run, install, deploy, or download must still include signed provenance attestations
+- **SBOM attestations and release assets** — Released binaries and container images must include signed SPDX and CycloneDX SBOM attestations when the build can generate them, and public releases should publish the same SBOM files as release assets
+- **Linked artifacts metadata** — Registry-published release artifacts should upload storage metadata to GitHub's linked artifacts page through `actions/attest` or the artifact metadata API
 
-### Verify SLSA Provenance
+Implementation requirements for provenance, SBOM attestations, linked artifacts uploads, and release verification are documented in [Artifact Attestations](./docs/security/artifact-attestations.md).
 
-For artifacts with SLSA provenance generated by slsa-github-generator:
-
-```bash
-# Install slsa-verifier
-go install github.com/slsa-framework/slsa-verifier/cli/[email protected]
-
-# Verify provenance
-slsa-verifier verify-artifact my-artifact \
-  --provenance-path my-artifact.intoto.jsonl \
-  --source-uri github.com/windlass-tech/my-repo \
-  --source-tag v1.0.0
-```
+## Verifying Artifacts
 
-### What Verification Checks
+Consumers can verify the authenticity, integrity, and provenance of artifacts from this organization using GitHub artifact attestations and SLSA provenance verification tools.
 
 Verification confirms:
 
 1. **Authenticity** — The artifact was built by the claimed repository
 2. **Integrity** — The artifact has not been tampered with since build
 3. **Provenance** — The artifact's build process is documented
-4. **Source** — The exact source code (commit SHA) used to build
-5. **Build environment** — The workflow that produced the artifact
-
-## Security Monitoring
-
-### Audit Logging
-
-- All workflow runs are logged via GitHub's audit log
-- Access to secrets is logged
-- Deployment activity is tracked
+4. **Source** — The exact source code revision used to build the artifact is known
+5. **Build environment** — The workflow that produced the artifact is identified
 
-### Vulnerability Scanning
-
-- Dependabot alerts are enabled on all repositories
-- Code scanning with CodeQL runs on all PRs
-- OSV Scanner runs on PRs and scheduled full scans
-- Secret scanning prevents credential leakage
-
-### Security Scorecard
-
-This organization uses [OpenSSF Scorecard](https://securityscorecards.dev/) to continuously monitor security posture:
-
-- Binary artifacts
-- Branch protection
-- Code review
-- Dependency update tool
-- Fuzzing
-- License
-- Maintained
-- Pinned dependencies
-- SAST
-- Security policy
-- Signed releases
-- Token permissions
-- Vulnerabilities
+Detailed verification commands for binaries, container images, SBOM attestations, and SLSA provenance are documented in [Artifact Attestations: Verification Expectations](./docs/security/artifact-attestations.md#verification-expectations).
 
 ## References
 
 Detailed reference lists for each topic are available in the companion documents:
 
 - [SLSA Framework references](./docs/security/slsa-compliance-framework.md#references)
-- [GitHub Security and Step Security references](./docs/security/workflow-hardening.md#references)
+- [GitHub Actions and Step Security references](./docs/security/workflow-hardening.md#references)
+- [Artifact attestation references](./docs/security/artifact-attestations.md#references)
 - [OSV Scanner and Additional Resources](./docs/security/dependency-security.md#references)