From 8e4c5e0de2006b6ed07efab8f7c38e0c10ca050b Mon Sep 17 00:00:00 2001 From: "well-architected-sync-bot[bot]" <235114805+well-architected-sync-bot[bot]@users.noreply.github.com> Date: Wed, 21 Jan 2026 02:26:52 +0000 Subject: [PATCH] Sync from github/github-well-architected-internal (main) Source Repository: github/github-well-architected-internal Source Branch: main Source SHA: 675aa8e583fa088520a3764f73555f053bc630e5 --- .../scenarios/nist-ssdf-implementation.md | 997 ++++++++++++++++++ package-lock.json | 41 +- 2 files changed, 1016 insertions(+), 22 deletions(-) create mode 100644 content/library/scenarios/nist-ssdf-implementation.md diff --git a/content/library/scenarios/nist-ssdf-implementation.md b/content/library/scenarios/nist-ssdf-implementation.md new file mode 100644 index 0000000..ac327d3 --- /dev/null +++ b/content/library/scenarios/nist-ssdf-implementation.md @@ -0,0 +1,997 @@ +--- +draft: false +title: "Implementing the NIST SSDF with GitHub" +publishDate: 2026-01-20 +params: + authors: [ + {name: "Greg Mohler", handle: "CallMeGreg"}, + ] + +pillars: + - application-security + - governance + - productivity + - collaboration + +areas: + - ci-cd-and-devops + - collaborative-coding + - developers + - enterprise-and-teams + - security + +verticals: + - finance + - government + - information-technology + +personas: + - administrator + - customer-internal-support + - developer + - project-manager + +platform: + - github-enterprise-cloud + - github-enterprise-cloud-plus-emu + - github-enterprise-server + +features: + - codespaces + - github-advanced-security + - github-actions + - issues-and-pull-requests + - repositories + +components: + - audit-log + - actions-oidc + - code-review-automation + - code-scanning + - dependabot-and-dependency-review + - governance-and-policy + - push-rulesets + - repository-custom-properties + - repository-rulesets + - secret-scanning + - security-configurations + - sso-saml + - sso-oidc + +github: + - customer-success-architect + - enterprise-support + - expert-services +--- + + + + + +## Scenario overview + +The [NIST Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final) (SSDF) provides a comprehensive set of practices for developing secure software throughout the software development lifecycle. Organizations subject to regulatory requirements, government contracts, or those seeking to implement industry-leading security practices often need to demonstrate compliance with the SSDF. + +This guide provides actionable recommendations for how GitHub Enterprise customers can leverage GitHub features and integrations to meet SSDF requirements. Each practice is categorized as: + +- **GitHub-native**: Can be implemented using built-in GitHub features +- **GitHub Integration**: Requires integration with external tools or services +- **Out of scope**: Relates to organizational processes or policies outside of GitHub's technical capabilities + +For organizations implementing the SSDF, GitHub provides a strong foundation across multiple practice areas including source code management, secure CI/CD pipelines, vulnerability detection, and supply chain security. This guide helps you understand which GitHub features to enable, how to configure them, and what additional integrations may be needed to achieve comprehensive SSDF compliance. + +The full NIST SSDF v1.1 specification is available at: NIST SP 800-218 + +## Key design strategies and checklist + +### Design strategies + +**Leverage GitHub-native security features**: GitHub provides extensive built-in capabilities for secure software development, including code scanning, secret scanning, Dependabot, and branch protection. Maximize use of these features before adding external integrations. + +**Implement defense in depth**: Use multiple layers of security controls including repository permissions, branch protection rules, required status checks, code review requirements, and security scanning. No single control should be the only barrier to introducing vulnerabilities. + +**Automate security checks in CI/CD**: Integrate security scanning, dependency checking, and policy enforcement directly into GitHub Actions workflows. Automated checks provide consistent enforcement and reduce human error. + +**Establish clear governance boundaries**: Use organization-level policies, repository rulesets, and custom properties to enforce security requirements consistently across repositories. Centralized governance reduces administrative overhead and ensures consistent application of security practices. For more detailed recommendations around repository rulesets and custom properties, see [Managing Repositories at Scale](https://wellarchitected.github.com/library/governance/recommendations/managing-repositories-at-scale/). + +**Maintain comprehensive audit trails**: Enable and preserve audit logs, workflow run histories, and security alert data. These artifacts provide evidence of security practices and support incident response and compliance reporting. + +### Implementation checklist + +- [ ] Configure organization-level security policies and settings +- [ ] Implement repository rulesets on all default branches +- [ ] Require code review approval before merging changes +- [ ] Enable secret scanning and push protection +- [ ] Enable Dependabot alerts and security updates +- [ ] Enable and configure code scanning to detect vulnerable coding patterns +- [ ] Perform dynamic/runtime security testing for executable code +- [ ] Use secure CI/CD build environments with least privilege permissions +- [ ] Configure required status checks for security scans in CI/CD +- [ ] Authenticate between CI/CD and cloud providers using OpenID Connect (OIDC) +- [ ] Implement role-based access control using teams and custom roles +- [ ] Enable SAML SSO or OIDC for user authentication to repositories +- [ ] Configure audit log streaming to a SIEM or log management system +- [ ] Establish processes for vulnerability triage and remediation +- [ ] Generate and maintain SBOMs for software releases +- [ ] Implement artifact attestations for build provenance +- [ ] Document security requirements in GitHub Issues or Projects +- [ ] Create security policies and incident response procedures +- [ ] Provide security training for developers and administrators +- [ ] Perform threat modeling and design reviews for critical applications + +## Assumptions and preconditions + +This implementation guide assumes: + +- **GitHub Enterprise deployment**: Your organization uses GitHub Enterprise Cloud (GHEC) or GitHub Enterprise Server (GHES). + +- **Administrative access**: You have organization owner or administrator privileges to configure organization-level security settings, policies, and integrations. + +- **Advanced Security licensing**: For private repositories, GitHub Advanced Security licenses are available to enable code scanning, secret scanning, and dependency review features. + +- **CI/CD pipeline adoption**: Your organization uses or plans to use GitHub Actions or integrated CI/CD tools for build and deployment automation. + +- **Identity provider integration**: Your organization has an identity provider (IdP) that can integrate with GitHub for SSO via SAML or OIDC. + +- **Security team involvement**: Security professionals are engaged in defining requirements, reviewing architecture, and managing vulnerability response processes. + +- **Commitment to secure development**: Leadership supports allocating time and resources to implement security practices throughout the SDLC. + +## Recommended deployment + +This section provides GitHub-specific implementation guidance for each NIST SSDF practice. Practices are organized by the framework's practice groups: + +- Prepare the Organization (PO) +- Protect the Software (PS) +- Produce Well-Secured Software (PW) +- Respond to Vulnerabilities (RV) + +### Prepare the Organization (PO) + +#### PO.1: Define security requirements for software development + +**Summary**: Establish and maintain security requirements for both development infrastructure and the software being developed. + +**GitHub implementation scope**: *GitHub-native* + +**Implementation details**: + +Use GitHub Issues and Projects to document, track, and maintain security requirements. + +1. Create a security requirements repository to centralize documentation +2. Use GitHub Issues to document individual security requirements with labels for categorization (e.g., `requirement:infrastructure`, `requirement:software`, `requirement:compliance`) +3. Create GitHub Projects boards to track requirement status and reviews +4. Use issue templates to standardize requirement documentation format +5. Enable Discussions for stakeholder input on evolving requirements +6. Link requirements to implementation work items for traceability + +{{< callout type="info" >}} +Create a [template project board](https://docs.github.com/enterprise-cloud@latest/issues/planning-and-tracking-with-projects/managing-your-project/managing-project-templates-in-your-organization) for security requirements or use the [copy project](https://docs.github.com/enterprise-cloud@latest/issues/planning-and-tracking-with-projects/creating-projects/copying-an-existing-project) feature to quickly set up boards for new projects or teams. +{{< /callout >}} + +**Configuration example**: + +```yaml +# .github/ISSUE_TEMPLATE/security-requirement.yml +name: Security Requirement +description: Document a security requirement for software development +title: "[REQ]: " +labels: ["security-requirement"] +body: + - type: dropdown + id: category + attributes: + label: Requirement Category + options: + - Infrastructure Security + - Software Security + - Process & Policy + - Compliance & Regulatory + - type: textarea + id: description + attributes: + label: Requirement Description + description: Detailed description of the security requirement + validations: + required: true + - type: textarea + id: rationale + attributes: + label: Rationale + description: Why this requirement is necessary + - type: dropdown + id: priority + attributes: + label: Priority + options: + - Critical + - High + - Medium + - Low +``` + +#### PO.2: Implement roles and responsibilities + +**Summary**: Define and assign security-related roles across the software development lifecycle, provide training, and obtain management commitment. + +**GitHub implementation scope**: *GitHub-native* for role definition and assignment; *Out of scope* for training programs and management commitment processes + +**Implementation details**: + +Use GitHub's built-in role-based access control features. + +1. **Organization roles**: Assign organization-level roles (Owner, Member) based on responsibilities, keeping the number of organization owners limited but more than one +2. **Team structure**: Create teams that align with SDLC roles (e.g., `security-champions`, `code-reviewers`, `release-managers`) +3. **Repository roles**: Use built-in repository roles (Admin, Maintain, Write, Triage, Read) or create custom repository roles +4. **CODEOWNERS**: Define code ownership and required reviewers using CODEOWNERS files +5. **Security managers role**: Use the security manager role to grant security teams visibility across the organization + +**CODEOWNERS example**: + +```text +# Default: all changes require at least one review +* @org/dev-team + +# Security-sensitive areas require review from a lead dev or security champion +/src/auth/** @org/lead-devs @org/security-champions +/src/crypto/** @org/lead-devs @org/security-champions +/src/payments/** @org/lead-devs @org/security-champions + +# CODEOWNERS and workflow files require lead dev review +/.github/CODEOWNERS @org/lead-devs +/.github/workflows/** @org/lead-devs +``` + +{{< callout type="info" >}} +Training programs and management commitment should be managed outside GitHub through your organization's learning management and communication systems. +{{< /callout >}} + +#### PO.3: Implement supporting toolchains + +**Summary**: Use automation tools throughout the SDLC to improve security, and configure them to generate artifacts demonstrating security practices. + +**GitHub implementation scope**: *GitHub Integration* + +**Implementation details**: + +Combine GitHub-native security features with Actions-based automation. + +**Enable organization-wide security features**: + +1. **Secret scanning and push protection**: Enable on all repositories to prevent credential exposure + - Navigate to Organization Settings > Code security and analysis + - Enable "Secret scanning" and "Push protection" for all repositories + - Consider enabling "Validity checks" for supported token types + +2. **Dependabot alerts, security updates, and dependency review**: Enable automatic vulnerability detection and remediation + - Enable "Dependabot alerts" for all repositories + - Enable "Dependabot security updates" to automatically create PRs for vulnerable dependencies + - Optionally enable "Grouped security updates" to reduce PR volume by combining related updates + - Use the [Dependency Review](https://github.com/actions/starter-workflows/blob/main/code-scanning/dependency-review.yml) action to detect and block new vulnerable dependencies in pull requests + +3. **Code scanning**: Set up automated SAST scanning using CodeQL or third-party tools + - Enable CodeQL analysis in all repositories + - Configure required status checks to block merges if vulnerabilities are detected above a certain severity + - Use the [CodeQL starter workflow](https://github.com/actions/starter-workflows/blob/main/code-scanning/codeql.yml) as a template for implementation + +4. **Immutable releases**: Prevent modifications to published releases + - Enable immutable releases on repositories to ensure release artifacts cannot be altered after publication + - This provides assurance that distributed software matches the original release + +5. **Artifact attestations**: Sign artifacts during build and validate provenance before consumption + - Use GitHub's artifact attestation feature to cryptographically sign build artifacts + - Enable consumers to verify artifact provenance and integrity using `gh attestation verify` + - Implements supply chain security best practices aligned with the [SLSA framework](https://slsa.dev/) + +#### PO.4: Define and use criteria for software security checks + +**Summary**: Establish criteria for evaluating software security and track compliance throughout the SDLC. + +**GitHub implementation scope**: *GitHub-native* + +**Implementation details**: + +Use GitHub repository rulesets to define and enforce software security policies. + +1. **Repository rulesets**: Create organization-level rulesets to monitor and enforce security requirements, monitoring any bypass activity +2. **Require code scanning results**: In your rulesets, define the security alert severity that should block pull request merges +3. **Status checks**: Use required status checks to enforce any additional criteria such as linters, unit tests, or custom security checks + +For more detailed examples of repository rulesets, see [Rulesets Best Practices](https://wellarchitected.github.com/library/governance/recommendations/managing-repositories-at-scale/rulesets-best-practices/). + +#### PO.5: Implement and maintain secure environments + +**Summary**: Protect development, build, test, and distribution environments from compromise. + +**GitHub implementation scope**: *GitHub Integration* + +**Implementation details**: + +Use GitHub Actions environments and secure runner practices. + +1. **GitHub Actions OIDC**: Use OIDC tokens instead of long-lived credentials for cloud access +2. **GitHub-hosted runners**: Use GitHub-hosted runners for CI/CD to leverage ephemeral, secure build environments +3. **Environments**: Use GitHub Actions [environments](https://docs.github.com/enterprise-cloud@latest/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments) with protection rules for deployment stages +4. **Repository visibility**: Default new repositories to private visibility + +**Environment protection rules**: + +```yaml +# Configure production environment protection +Environment: production +Protection rules: +- Required reviewers: release-managers team +- Wait timer: 30 minutes +- Deployment branches: Only protected branches (main, release/*) +- Environment secrets: Use scoped secrets with minimal permissions +``` + +Leverage GitHub-hosted runners for most CI/CD workloads to benefit from automatic updates, security patches, and isolation. If self-hosted runners are necessary, follow these best practices: + +- Run self-hosted runners on ephemeral VMs or containers +- Use separate runner groups for different security zones +- Restrict runner group access to specific repositories or organizations +- Never use self-hosted runners for public repositories +- Monitor audit logs for runner activity + +### Protect the Software (PS) + +#### PS.1: Protect all forms of code from unauthorized access and tampering + +**Summary**: Restrict access to source code, executables, and configuration-as-code based on the principle of least privilege. + +**GitHub implementation scope**: *GitHub Integration* + +**Implementation details**: + +Combine GitHub-native access controls with your identity provider. + +1. **Authentication**: Require SAML SSO or OIDC for organization access +2. **Multi-factor authentication**: Enforce MFA for all users +3. **IP allow lists**: Restrict access to GitHub from approved IP ranges +4. **Repository permissions**: Use team-based access control with least privilege +5. **Repository rulesets**: Prevent direct commits to protected branches +6. **Required reviews**: Mandate code owner review for all changes +7. **Push protection**: Enable secret scanning push protection to prevent credential commits +8. **Push rulesets**: Use push rulesets to further restrict changes to sensitive file paths + +#### PS.2: Provide a mechanism for verifying software release integrity + +**Summary**: Enable software acquirers to verify that releases are legitimate and untampered. + +**GitHub implementation scope**: *GitHub Integration* + +**Implementation details**: + +Use artifact attestations to enable build provenance verification. + +1. **Artifact attestations**: Generate cryptographic attestations for build artifacts using GitHub's [artifact attestation](https://docs.github.com/enterprise-cloud@latest/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations) feature +2. **Immutable releases**: Leverage GitHub's [immutable releases](https://docs.github.com/enterprise-cloud@latest/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases) feature to prevent post-release modifications + +**Artifact attestation workflow**: + +```yaml +name: Build and Attest Container Image +on: + push: + tags: + - 'v*' + +permissions: + contents: read + id-token: write + attestations: write + +jobs: + build-and-attest: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v5 + + - name: Set up Docker Buildx + uses: docker/setup-buildx-action@v3 + + - name: Login to Docker Hub + uses: docker/login-action@v3 + with: + username: ${{ secrets.DOCKERHUB_USERNAME }} + password: ${{ secrets.DOCKERHUB_TOKEN }} + + - name: Extract metadata + id: meta + uses: docker/metadata-action@v5 + with: + images: myorg/myapp + tags: | + type=semver,pattern={{version}} + type=semver,pattern={{major}}.{{minor}} + + - name: Build and push + id: push + uses: docker/build-push-action@v6 + with: + context: . + push: true + tags: ${{ steps.meta.outputs.tags }} + labels: ${{ steps.meta.outputs.labels }} + + - name: Generate artifact attestation + uses: actions/attest-build-provenance@v3 + with: + subject-name: myorg/myapp + subject-digest: ${{ steps.push.outputs.digest }} + push-to-registry: true +``` + +**Verification for consumers**: + +```bash +# Verify container image attestation using the GitHub CLI +gh attestation verify oci://myorg/myapp:v1.0.0 --owner my-org +``` + +#### PS.3: Archive and protect each software release + +**Summary**: Preserve release artifacts and provenance data to support vulnerability analysis and incident response. + +**GitHub implementation scope**: *GitHub Integration* + +**Implementation details**: + +1. **GitHub Releases**: Create immutable releases for each version +2. **Release artifacts**: Attach binaries, containers, and other artifacts +3. **Tag protection**: Protect release tags from deletion or modification using [tag rulesets](https://docs.github.com/enterprise-cloud@latest/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization#creating-a-branch-or-tag-ruleset) +4. **SBOM generation**: Generate and attach SBOMs to releases + +**SBOM generation workflow**: + +```yaml +name: Generate SBOM +on: + push: + tags: + - 'v*' + +permissions: + id-token: write + attestations: write + contents: read + +jobs: + build-and-generate-sbom: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v5 + + # Build steps for your software would go here + + - name: Generate SBOM + uses: anchore/sbom-action@v0 + with: + format: spdx-json + output-file: sbom.spdx.json + + - name: Attest SBOM + uses: actions/attest-sbom@v3 + with: + subject-path: '${{ github.workspace }}' + sbom-path: 'sbom.spdx.json' +``` + +### Produce Well-Secured Software (PW) + +#### PW.1: Design software to meet security requirements and mitigate security risks + +**Summary**: Use risk modeling to identify security requirements and design decisions. + +**GitHub implementation scope**: *GitHub-native* for documentation and tracking; *Out of scope* for threat modeling tools and methodologies + +**Implementation details**: + +Document threat models and security decisions in GitHub. + +1. Use GitHub Issues to track security requirements derived from threat modeling +2. Use GitHub Projects to manage security risk mitigation efforts +3. Link security design decisions to implementation pull requests + +{{< callout type="info" >}} +Threat modeling tools and methodologies should be selected based on organizational preferences. Results can be documented in GitHub. +{{< /callout >}} + +#### PW.2: Review the software design to verify compliance with security requirements + +**Summary**: Have qualified reviewers confirm that software design meets security requirements. + +**GitHub implementation scope**: *GitHub-native* + +**Implementation details**: Use GitHub Projects to track security requirements and verify design compliance. + +1. **Link security requirements to design reviews**: Reference security requirement issues (from PO.1) +2. **Security team project access**: Grant security teams read/write access to project boards tracking security requirements +3. **Design compliance verification**: Security team reviews project boards to ensure all in-scope requirements are addressed in the design +4. **Status tracking**: Reviewers validate designs and comment their approval or required changes in the related issue + +#### PW.3: Verify third-party software complies with security requirements + +{{< callout type="info" >}} +PW.3 has been replaced by PO.1 and PW.4 in NIST SSDF v1.1 +{{< /callout >}} + +#### PW.4: Reuse existing, well-secured software when feasible + +**Summary**: Use vetted libraries and components instead of reimplementing functionality. + +**GitHub implementation scope**: *GitHub-native* + +**Implementation details**: + +Use GitHub policies and dependency management features to enforce secure software reuse. + +1. **GitHub Actions policies**: Set [enterprise policies](https://docs.github.com/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#policies) to only allow actions created by GitHub, verified Marketplace creators, or those that have been explicitly approved. + +Navigate to Enterprise Policies > Actions > Policies > and configure: + +- [ ] Allow all actions and reusable workflows +- [ ] Allow enterprise actions and reusable workflows +- [x] Allow enterprise, and select non-enterprise, actions and reusable workflows + - [x] Allow actions created by GitHub + - [x] Allow actions by Marketplace verified creators + - [x] Allow or block specified actions and reusable workflows + - actions/* + - github/* + - docker/* + - [etc...] + +2. **OIDC for cloud access**: Enforce authentication to cloud providers through [Actions OIDC](https://docs.github.com/enterprise-cloud@latest/actions/concepts/security/openid-connect) with centralized reusable workflows. + +Create reusable workflows that handle cloud authentication using OIDC, restricting access with a [trust condition](https://docs.github.com/enterprise-cloud@latest/actions/how-tos/secure-your-work/security-harden-deployments/oidc-with-reusable-workflows) that includes the `job_workflow_ref` variable. This prevents repositories from configuring cloud access directly and ensures consistent security controls. Store the cloud provider secrets (client ID, tenant ID, subscription ID) as organization secrets so they can be inherited by the caller workflows. + +Example reusable workflow for Azure access: + +```yaml +# .github/workflows/reusable-azure-deploy.yml in your .github repository +name: Reusable Azure Deployment +on: + workflow_call: + inputs: + environment: + required: true + type: string + description: 'Target environment (dev, staging, prod)' + azure-region: + required: true + type: string + description: 'Azure region for deployment' + secrets: + azure-client-id: + required: true + description: 'Azure client ID for OIDC authentication' + azure-tenant-id: + required: true + description: 'Azure tenant ID for OIDC authentication' + azure-subscription-id: + required: true + description: 'Azure subscription ID for deployment' + +permissions: + id-token: write + contents: read + +jobs: + deploy: + runs-on: ubuntu-latest + environment: ${{ inputs.environment }} + steps: + - uses: actions/checkout@v5 + + - name: Azure Login using OIDC + uses: azure/login@v2 + with: + client-id: ${{ secrets.azure-client-id }} + tenant-id: ${{ secrets.azure-tenant-id }} + subscription-id: ${{ secrets.azure-subscription-id }} + + # Deployment steps would follow + - name: Deploy to Azure + run: | + echo "Deploying to ${{ inputs.environment }} in ${{ inputs.azure-region }}" + # Add your deployment commands here +``` + +Consumer repositories call this workflow instead of configuring cloud access directly: + +```yaml +# In a repository's .github/workflows/deploy.yml +name: Deploy to Azure +on: + push: + branches: [main] + +jobs: + deploy: + uses: my-org/.github/.github/workflows/reusable-azure-deploy.yml@main + with: + environment: production + azure-region: eastus + secrets: + azure-client-id: ${{ secrets.AZURE_CLIENT_ID }} + azure-tenant-id: ${{ secrets.AZURE_TENANT_ID }} + azure-subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} +``` + +Benefits of centralized OIDC workflows: + +- No long-lived cloud credentials stored in GitHub secrets +- Consistent security controls across all cloud deployments +- Centralized audit trail of cloud access +- Simplified credential rotation and revocation +- Reduced blast radius if a repository is compromised + +3. **Dependabot alerts**: Enable Dependabot [alerts](https://docs.github.com/enterprise-cloud@latest/code-security/dependabot/dependabot-alerts/about-dependabot-alerts) and automated [security updates](https://docs.github.com/enterprise-cloud@latest/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates) for known vulnerabilities in dependencies. + +4. **Dependency review**: Use the [dependency review](https://github.com/actions/dependency-review-action) action to block new vulnerable dependencies and open-source software with non-compliant licenses. + +For example: + +```yaml +name: Dependency Review +on: [pull_request] + +permissions: + contents: read + pull-requests: write + +jobs: + dependency-review: + runs-on: ubuntu-latest + steps: + - name: Checkout code + uses: actions/checkout@v5 + + - name: Dependency Review + uses: actions/dependency-review-action@v4 + with: + # Block pull requests with vulnerabilities at moderate severity or higher + fail-on-severity: moderate + # Block dependencies with incompatible licenses + deny-licenses: GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-3.0, AGPL-3.0 + # Post detailed summary in PR comments + comment-summary-in-pr: always +``` + +Make dependency review a required workflow in your repository rulesets to prevent merging pull requests that introduce vulnerable or non-compliant dependencies. + +#### PW.5: Create source code by adhering to secure coding practices + +**Summary**: Follow secure coding standards to minimize vulnerabilities. + +**GitHub implementation scope**: *GitHub-native* + +**Implementation details**: + +1. **Code scanning**: Enable CodeQL (or other SAST tools) for automated code analysis +2. **Require code scanning results**: Block merges if code scanning finds vulnerabilities beyond a specific severity +3. **Security configurations**: Use GitHub [security configurations](https://docs.github.com/enterprise-cloud@latest/code-security/securing-your-organization/introduction-to-securing-your-organization-at-scale/choosing-a-security-configuration-for-your-repositories) to standardize settings across repositories + +Refer to the CodeQL starter workflow for implementation details: [CodeQL starter workflow](https://github.com/actions/starter-workflows/blob/main/code-scanning/codeql.yml) + +#### PW.6: Configure the compilation, interpreter, and build processes to improve executable security + +**Summary**: Ensure build processes use secure tools and configurations in highly controlled environments. + +**GitHub implementation scope**: *GitHub-native* + +**Implementation details**: + +Use GitHub-hosted runners to provide secure, ephemeral build environments with up-to-date software. + +1. **GitHub-hosted runners**: Use GitHub-hosted runners for all CI/CD workflows to leverage: + - Automatically updated operating systems and build tools + - Ephemeral environments that are destroyed after each job + - Isolation between builds preventing cross-contamination + - Consistent, hardened base images maintained by GitHub + +2. **Runner image selection**: Choose appropriate runner images based on your build requirements: + - `ubuntu-latest`, `windows-latest`, `macos-latest` for standard builds + - Larger runner sizes (`ubuntu-latest-4-core`, `ubuntu-latest-8-core`) for resource-intensive builds + - Runner images are updated weekly with security patches and toolchain updates + +3. **Workflow security configurations**: + - Use pinned action versions with commit SHAs for supply chain security + - Minimize workflow permissions using the `permissions` key + - Avoid using self-hosted runners unless absolutely necessary for specialized hardware or network requirements + +{{< callout type="info" >}} +GitHub-hosted runners provide a secure-by-default build environment. If self-hosted runners are required, run them on ephemeral VMs or containers, use separate runner groups for different security zones, and never use them for public repositories. +{{< /callout >}} + +#### PW.7: Review and/or analyze human-readable code to identify vulnerabilities + +**Summary**: Use manual and automated code review to find security issues. + +**GitHub implementation scope**: *GitHub-native* + +**Implementation details**: + +1. **Pull request reviews**: Require human code review for all changes to default and protected branches +2. **Code scanning**: Automated SAST scanning with CodeQL (or third-party tools) +3. **Review assignments**: Automatically assign security champions as reviewers using pull request templates or CODEOWNERS files. +4. **Code suggestions**: Use review comments to propose security fixes + +Here is an example repository ruleset configuration to enforce automated review by CodeQL + manual review: + +- [x] Require pull request reviews before merging + - [x] Required approving reviews: 1 + - [x] Require review from Code Owners + +- [x] Require code scanning results + - [x] CodeQL - Security alerts: `High or higher`, Alerts: `Error` + +- [x] Automatically request Copilot code review + +{{< callout type="info" >}} +Tip: Use Copilot code review with [custom instructions](https://docs.github.com/enterprise-cloud@latest/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review?tool=webui#customizing-copilots-reviews-with-custom-instructions) that include an emphasis on security to automate initial code security review. +{{< /callout >}} + +#### PW.8: Test executable code to identify vulnerabilities + +**Summary**: Use dynamic testing, fuzzing, and other runtime analysis to find security issues. + +**GitHub implementation scope**: *GitHub Integration* + +**Implementation details**: + +Integrate testing tools into GitHub Actions and upload SARIF results to GitHub code scanning. + +1. **DAST integration**: Run dynamic application security testing on test deployments using Actions workflows +2. **Container scanning**: Scan container images for vulnerabilities using third-party Actions (e.g., Trivy) +3. **Penetration testing**: Document penetration testing findings in GitHub Issues + +**Example container scanning workflow**: + +```yaml +name: Container Security Scan +on: + push: + branches: [main] + pull_request: + +jobs: + scan: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v5 + + - name: Build container image + run: docker build -t myapp:${{ github.sha }} . + + - name: Run Trivy scanner + uses: aquasecurity/trivy-action@b6643a29fecd7f34b3597bc6acb0a98b03d33ff8 # v0.33.1 + with: + image-ref: 'myapp:${{ github.sha }}' + format: 'sarif' + output: 'trivy-results.sarif' + severity: 'CRITICAL,HIGH' + + - name: Upload Trivy results to GitHub Security + uses: github/codeql-action/upload-sarif@v3 + with: + sarif_file: 'trivy-results.sarif' +``` + +#### PW.9: Configure software to use secure settings by default + +**Summary**: Verify that released software has secure default configurations. + +**GitHub implementation scope**: *Out of scope* + +### Respond to Vulnerabilities (RV) + +#### RV.1: Identify and confirm vulnerabilities on an ongoing basis + +**Summary**: Continuously monitor for new vulnerabilities in software and dependencies. + +**GitHub implementation scope**: *GitHub-native* + +**Implementation details**: + +1. **Security Overview**: Use the multi-level [Security Overview](https://docs.github.com/enterprise-cloud@latest/code-security/security-overview/about-security-overview) dashboard to monitor vulnerability status: + - **Enterprise level**: Aggregate security posture across all organizations + - **Organization level**: View alert trends, coverage gaps, and enablement status across repositories + - **Repository level**: Detailed alert status and remediation progress + +2. **Audit log streaming**: Stream [audit log events](https://docs.github.com/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise) to your SIEM for long-term retention, correlation with other security events, and compliance reporting. + +3. **Webhooks for automated response**: Configure [webhooks](https://docs.github.com/enterprise-cloud@latest/webhooks/about-webhooks) to automatically respond to security alert events. + +#### RV.2: Assess, prioritize, and remediate vulnerabilities + +**Summary**: Triage and fix identified vulnerabilities based on risk. + +**GitHub implementation scope**: *GitHub-native* + +**Implementation details**: + +1. **Security alerts**: Review and triage alerts in the Security tab +2. **Dependabot security updates**: Automatically generate PRs for dependency updates +3. **Repository custom properties**: Use [custom properties](https://docs.github.com/enterprise-cloud@latest/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization) to classify repositories by business criticality, enabling risk-based prioritization of alerts +4. **Security campaigns**: Use [security campaigns](https://docs.github.com/enterprise-cloud@latest/code-security/securing-your-organization/tracking-security-work-across-your-organization/about-security-campaigns) to prioritize and coordinate remediation of specific alert types across repositories +5. **Copilot Autofix**: Use [Copilot Autofix](https://docs.github.com/enterprise-cloud@latest/code-security/code-scanning/managing-code-scanning-alerts/about-autofix-for-codeql-code-scanning) to automatically generate fix suggestions for vulnerabilities identified by CodeQL + +{{< callout type="info" >}} +For more detailed guidance per alert type, refer to [Prioritizing Security Alert Remediation](https://wellarchitected.github.com/library/application-security/recommendations/prioritizing-alerts/). +{{< /callout >}} + +#### RV.3: Analyze vulnerabilities to identify their root causes + +**Summary**: Perform root cause analysis to prevent similar vulnerabilities. + +**GitHub implementation scope**: *GitHub-native* + +**Implementation details**: + +1. Use GitHub Issues to document root cause analysis +2. Link related vulnerabilities using issue references +3. Create post-mortem templates for security incidents +4. Track systemic issues in Projects +5. Use Discussions for collaborative analysis + +**Root cause analysis template**: + +```markdown +## Vulnerability Root Cause Analysis + +**Vulnerability ID**: CVE-YYYY-XXXXX or GHSA-XXXXX +**Date Identified**: YYYY-MM-DD +**Severity**: Critical/High/Medium/Low + +### Summary +Brief description of the vulnerability. + +### Root Cause +What underlying issue allowed this vulnerability to exist? + +### Contributing Factors +- Development process gaps +- Tool/automation gaps +- Training gaps +- Design/architecture issues + +### Similar Issues +- Link to related vulnerabilities +- Common patterns identified + +### Preventive Actions +- [ ] Process improvements +- [ ] Tool/automation enhancements +- [ ] Training updates +- [ ] Architecture changes +- [ ] Code scanning rules + +### Lessons Learned +Key takeaways to prevent recurrence. +``` + +## Additional solution detail and trade-offs to consider + +### Implementation approach + +**Phased rollout**: Implementing NIST SSDF compliance across an organization is a significant undertaking. Consider a phased approach: + +1. **Phase 1 - Foundation**: Enable core security features (SSO, MFA, audit logging) +2. **Phase 2 - Detection**: Activate scanning capabilities (code scanning, secret scanning, Dependabot) +3. **Phase 3 - Enforcement**: Implement rulesets, required workflows, and automated policy enforcement +4. **Phase 4 - Optimization**: Fine-tune configurations, develop custom queries, and streamline processes + +**Pilot programs**: Start with a subset of critical repositories (5-10 repositories) or teams to validate configurations and workflows before organization-wide rollout. Successful pilots typically run 4-6 weeks and identify ~80% of edge cases and configuration issues before broader deployment. + +**Lessons learned from field deployments**: + +- Communicate early and often with development teams about upcoming changes +- Provide self-service documentation and troubleshooting guides +- Establish clear escalation paths for security exceptions +- Celebrate quick wins and security improvements to build momentum + +### GitHub Enterprise Cloud vs. Server + +**GitHub Enterprise Cloud** provides the most comprehensive feature set for SSDF compliance. + +**GitHub Enterprise Server** supports most SSDF practices but may lag behind Cloud in feature availability. Organizations with air-gapped or on-premises requirements should evaluate feature parity for their GHES version. + +**GitHub Enterprise Cloud with Enterprise Managed Users (EMU)** provides enhanced security and governance for organizations requiring strict control over identity and access management. + +### Tool integration trade-offs + +**GitHub-native vs. third-party tools**: GitHub Advanced Security provides comprehensive scanning capabilities that integrate seamlessly with the platform. However, organizations may need to supplement with specialized tools for: + +- Interactive application security testing (IAST) +- Runtime application self-protection (RASP) +- Dynamic application security testing (DAST) +- Container scanning +- Threat modeling + +**Integration approach**: When integrating external tools: + +- Use GitHub Actions for orchestration +- Upload code scanning results to GitHub Security tab using SARIF format +- Implement tools as required status checks + +### Automation boundaries + +**What to automate**: Security scanning, dependency updates, policy enforcement, artifact generation, and basic triage should be fully automated to ensure consistency and reduce human error. + +**What requires human judgment**: Security design reviews, risk acceptance decisions, root cause analysis, and security exceptions require human expertise and should not be fully automated. + +### Audit and compliance considerations + +**Evidence generation**: GitHub provides extensive audit trails through: + +- Audit log API and streaming +- Workflow run histories and artifacts +- Security alert histories +- Git commit history +- Release artifacts and attestations + +**Retention requirements**: Configure audit log streaming to a SIEM or log management system for long-term retention that exceeds GitHub's default retention periods. + +**Third-party audits**: GitHub's audit capabilities and artifact generation features provide evidence for SOC 2, FedRAMP, and other compliance audits. Ensure your configuration generates the specific artifacts required by your auditors. + +### Performance and scalability + +**Code scanning impact**: CodeQL and other SAST tools can increase CI/CD pipeline duration. Optimize by: + +- Parallelizing scans across languages +- Caching build dependencies +- Using larger runners for resource-intensive scans + +**Large organization scaling**: Organizations with thousands of repositories should: + +- Use organization-level rulesets instead of per-repository configuration +- Leverage security configurations for consistent settings across repositories +- Use required workflows to enforce security scans +- Implement repository custom properties for targeted policy application + +### Common implementation challenges + +**Developer experience**: Security controls can be perceived as friction. Address this by: + +- Providing clear documentation and training +- Automating fix suggestions (Copilot Autofix, Dependabot PRs) +- Establishing reasonable response SLAs +- Creating fast feedback loops +- Offering self-service exception processes for legitimate use cases + +**False positive management**: Scanning tools can generate false positives. Mitigate by: + +- Documenting alert dismissal rationales +- Regularly reviewing dismissed alert reasons + +**Legacy code challenges**: Existing codebases may have numerous security findings. Approach with: + +- Risk-based prioritization focusing on high-severity issues +- Gradual remediation tied to normal development work +- Clear separation of new vs. legacy code expectations +- Baseline establishment with improvement targets + +### Cost considerations + +**Actions minutes**: Security scanning consumes Actions minutes. Manage costs through: + +- Using larger runners for faster execution +- Optimizing scan frequency +- Leveraging caching + +**External tool costs**: Third-party integrations may have separate licensing costs. Evaluate whether GitHub-native features can meet requirements before adding external tools. + +## Seeking further assistance + +{{% seeking-further-assistance-details %}} + +## Related links + +{{% related-links-github-docs %}} + +### External resources + +- [NIST SP 800-218: Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final) +- [Supply-chain Levels for Software Artifacts (SLSA)](https://slsa.dev/) diff --git a/package-lock.json b/package-lock.json index 0b23eca..1b8c94e 100644 --- a/package-lock.json +++ b/package-lock.json @@ -79,6 +79,7 @@ "resolved": "https://registry.npmjs.org/@babel/core/-/core-7.28.4.tgz", "integrity": "sha512-2BCOP7TN8M+gVDj7/ht3hsaO/B/n5oDbiAyyvnRlNOs+u1o+JWNYTQrmpuNp1/Wq2gcFrI01JAW+paEKDMx/CA==", "license": "MIT", + "peer": true, "dependencies": { "@babel/code-frame": "^7.27.1", "@babel/generator": "^7.28.3", @@ -1956,7 +1957,6 @@ "resolved": "https://registry.npmjs.org/@emotion/is-prop-valid/-/is-prop-valid-1.3.1.tgz", "integrity": "sha512-/ACwoqx7XQi9knQs/G0qKvv5teDMhD7bXYns9N/wM8ah8iNb8jZ2uNO0YOgiq2o2poIvVtJS2YALasQuMSQ7Kw==", "license": "MIT", - "peer": true, "dependencies": { "@emotion/memoize": "^0.9.0" } @@ -1965,22 +1965,19 @@ "version": "0.9.0", "resolved": "https://registry.npmjs.org/@emotion/memoize/-/memoize-0.9.0.tgz", "integrity": "sha512-30FAj7/EoJ5mwVPOWhAyCX+FPfMDrVecJAM+Iw9NRoSl4BBAQeqj4cApHHUXOVvIPgLVDsCFoz/hGD+5QQD1GQ==", - "license": "MIT", - "peer": true + "license": "MIT" }, "node_modules/@emotion/stylis": { "version": "0.8.5", "resolved": "https://registry.npmjs.org/@emotion/stylis/-/stylis-0.8.5.tgz", "integrity": "sha512-h6KtPihKFn3T9fuIrwvXXUOwlx3rfUvfZIcP5a6rh8Y7zjE3O06hT5Ss4S/YI1AYhuZ1kjaE/5EaOOI2NqSylQ==", - "license": "MIT", - "peer": true + "license": "MIT" }, "node_modules/@emotion/unitless": { "version": "0.7.5", "resolved": "https://registry.npmjs.org/@emotion/unitless/-/unitless-0.7.5.tgz", "integrity": "sha512-OWORNpfjMsSSUBVrRBVGECkhWcULOAJz9ZW8uK9qgxD+87M7jHRcvh/A96XXNhXTLmKcoYSQtBEX7lHMO7YRwg==", - "license": "MIT", - "peer": true + "license": "MIT" }, "node_modules/@github/relative-time-element": { "version": "4.4.8", @@ -3845,6 +3842,7 @@ "resolved": "https://registry.npmjs.org/@types/react/-/react-19.2.2.tgz", "integrity": "sha512-6mDvHUFSjyT2B2yeNx2nUgMxh9LtOWvkhIU3uePn2I2oyNymUAX1NIsdgviM4CH+JSrp2D2hsMvJOkxY+0wNRA==", "license": "MIT", + "peer": true, "dependencies": { "csstype": "^3.0.2" } @@ -3855,6 +3853,7 @@ "integrity": "sha512-/EEvYBdT3BflCWvTMO7YkYBHVE9Ci6XdqZciZANQgKpaiDRGOLIlRo91jbTNRQjgPFWVaRxcYc0luVNFitz57A==", "devOptional": true, "license": "MIT", + "peer": true, "peerDependencies": { "@types/react": "^19.2.0" } @@ -4416,6 +4415,7 @@ "integrity": "sha512-NZyJarBfL7nWwIq+FDL6Zp/yHEhePMNnnJ0y3qfieCrmNvYct8uvtiV41UvlSe6apAfk0fY1FbWx+NwfmpvtTg==", "dev": true, "license": "MIT", + "peer": true, "bin": { "acorn": "bin/acorn" }, @@ -4442,6 +4442,7 @@ "integrity": "sha512-B/gBuNg5SiMTrPkC+A2+cW0RszwxYmn6VYxB/inlBStS5nx6xHIt/ehKRhIMhqusl7a8LjQoZnjCs5vhwxOQ1g==", "dev": true, "license": "MIT", + "peer": true, "dependencies": { "fast-deep-equal": "^3.1.3", "fast-uri": "^3.0.1", @@ -4683,7 +4684,6 @@ "resolved": "https://registry.npmjs.org/babel-plugin-styled-components/-/babel-plugin-styled-components-2.1.4.tgz", "integrity": "sha512-Xgp9g+A/cG47sUyRwwYxGM4bR/jDRg5N6it/8+HxCnbT5XNKSKDT9xm4oag/osgqjC2It/vH0yXsomOG6k558g==", "license": "MIT", - "peer": true, "dependencies": { "@babel/helper-annotate-as-pure": "^7.22.5", "@babel/helper-module-imports": "^7.22.5", @@ -4807,6 +4807,7 @@ } ], "license": "MIT", + "peer": true, "dependencies": { "baseline-browser-mapping": "^2.8.9", "caniuse-lite": "^1.0.30001746", @@ -4863,7 +4864,6 @@ "resolved": "https://registry.npmjs.org/camelize/-/camelize-1.0.1.tgz", "integrity": "sha512-dU+Tx2fsypxTgtLoE36npi3UqcjSSMNYfkqgmoEhtZrraP5VWq0K7FkWVTYa8eMPtnU/G2txVsfdCJTn9uzpuQ==", "license": "MIT", - "peer": true, "funding": { "url": "https://github.com/sponsors/ljharb" } @@ -5206,7 +5206,6 @@ "resolved": "https://registry.npmjs.org/css-color-keywords/-/css-color-keywords-1.0.0.tgz", "integrity": "sha512-FyyrDHZKEjXDpNJYvVsV960FiqQyXc/LlYmsxl2BcdMb2WPx0OGRVgTg55rPSyLSNMqP52R9r8geSp7apN3Ofg==", "license": "ISC", - "peer": true, "engines": { "node": ">=4" } @@ -5265,7 +5264,6 @@ "resolved": "https://registry.npmjs.org/css-to-react-native/-/css-to-react-native-3.2.0.tgz", "integrity": "sha512-e8RKaLXMOFii+02mOlqwjbD00KSEKqblnpO9e++1aXS1fPQOpS1YoqdVHBqPjHNoxeF2mimzVqawm2KCbEdtHQ==", "license": "MIT", - "peer": true, "dependencies": { "camelize": "^1.0.0", "css-color-keywords": "^1.0.0", @@ -6121,7 +6119,6 @@ "resolved": "https://registry.npmjs.org/hoist-non-react-statics/-/hoist-non-react-statics-3.3.2.tgz", "integrity": "sha512-/gGivxi8JPKWNm/W0jSmzcMPpfpPLc3dY/6GxhX2hQ9iGj3aDfklV4ET7NjKpSinLpJ5vafa9iiGIEZg10SfBw==", "license": "BSD-3-Clause", - "peer": true, "dependencies": { "react-is": "^16.7.0" } @@ -6130,8 +6127,7 @@ "version": "16.13.1", "resolved": "https://registry.npmjs.org/react-is/-/react-is-16.13.1.tgz", "integrity": "sha512-24e6ynE2H+OKt4kqsOvNd8kBpV65zoxbA4BVsEOB3ARVWQki/DHzaUoC5KuON/BiccDaCCTZBuOcfZs70kR8bQ==", - "license": "MIT", - "peer": true + "license": "MIT" }, "node_modules/hsluv": { "version": "1.0.1", @@ -7680,8 +7676,7 @@ "version": "4.17.21", "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz", "integrity": "sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZVGedAJv8XZ1tvj5FvSg==", - "license": "MIT", - "peer": true + "license": "MIT" }, "node_modules/lodash.debounce": { "version": "4.0.8", @@ -9416,6 +9411,7 @@ } ], "license": "MIT", + "peer": true, "dependencies": { "nanoid": "^3.3.11", "picocolors": "^1.1.1", @@ -9522,6 +9518,7 @@ "resolved": "https://registry.npmjs.org/prettier/-/prettier-3.6.2.tgz", "integrity": "sha512-I7AIg5boAr5R0FFtJ6rCfD+LFsWHp81dolrFD8S79U9tb8Az2nGrJncnMSnys+bpQJfRUzqs9hnA81OAA3hCuQ==", "dev": true, + "peer": true, "bin": { "prettier": "bin/prettier.cjs" }, @@ -9700,8 +9697,7 @@ "version": "19.1.0", "resolved": "https://registry.npmjs.org/react-is/-/react-is-19.1.0.tgz", "integrity": "sha512-Oe56aUPnkHyyDxxkvqtd7KkdQP5uIUfHxd5XTb3wE9d/kRnZLmKbDB0GWk919tdQ+mxxPtG6EAs6RMT6i1qtHg==", - "license": "MIT", - "peer": true + "license": "MIT" }, "node_modules/react-markdown": { "version": "10.1.0", @@ -10141,8 +10137,7 @@ "version": "1.1.0", "resolved": "https://registry.npmjs.org/shallowequal/-/shallowequal-1.1.0.tgz", "integrity": "sha512-y0m1JoUZSlPAjXVtPPW70aZWfIL/dSP7AFkRnniLCrK/8MDKog3TySTBmckD+RObVxH0v4Tox67+F14PdED2oQ==", - "license": "MIT", - "peer": true + "license": "MIT" }, "node_modules/shebang-command": { "version": "2.0.0", @@ -10497,7 +10492,6 @@ "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-3.0.0.tgz", "integrity": "sha512-sKJf1+ceQBr4SMkvQnBDNDtf4TXpVhVGateu0t918bl30FnbE2m4vNLX+VWe/dpjlb+HugGYzW7uQXH98HPEYw==", "license": "MIT", - "peer": true, "engines": { "node": ">=4" } @@ -10507,7 +10501,6 @@ "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-5.5.0.tgz", "integrity": "sha512-QjVjwdXIt408MIiAqCX4oUKsgU2EqAGzs2Ppkm4aQYbjm+ZEWEcW4SfFNTr4uMNZma0ey4f5lgLrkB0aX0QMow==", "license": "MIT", - "peer": true, "dependencies": { "has-flag": "^3.0.0" }, @@ -10785,6 +10778,7 @@ "integrity": "sha512-5gTmgEY/sqK6gFXLIsQNH19lWb4ebPDLA4SdLP7dsWkIXHWlG66oPuVvXSGFPppYZz8ZDZq0dYYrbHfBCVUb1Q==", "dev": true, "license": "MIT", + "peer": true, "engines": { "node": ">=12" }, @@ -10924,6 +10918,7 @@ "integrity": "sha512-jl1vZzPDinLr9eUt3J/t7V6FgNEw9QjvBPdysz9KfQDD41fQrC2Y4vKQdiaUpFT4bXlb1RHhLpp8wtm6M5TgSw==", "dev": true, "license": "Apache-2.0", + "peer": true, "bin": { "tsc": "bin/tsc", "tsserver": "bin/tsserver" @@ -11232,6 +11227,7 @@ "integrity": "sha512-7h/weGm9d/ywQ6qzJ+Xy+r9n/3qgp/thalBbpOi5i223dPXKi04IBtqPN9nTd+jBc7QKfvDbaBnFipYp4sJAUQ==", "dev": true, "license": "MIT", + "peer": true, "dependencies": { "@types/eslint-scope": "^3.7.7", "@types/estree": "^1.0.8", @@ -11281,6 +11277,7 @@ "integrity": "sha512-MfwFQ6SfwinsUVi0rNJm7rHZ31GyTcpVE5pgVA3hwFRb7COD4TzjUUwhGWKfO50+xdc2MQPuEBBJoqIMGt3JDw==", "dev": true, "license": "MIT", + "peer": true, "dependencies": { "@discoveryjs/json-ext": "^0.6.1", "@webpack-cli/configtest": "^3.0.1",