From b3ed02cf51f649abfa77398ec49d0561af716959 Mon Sep 17 00:00:00 2001 From: Boy Steven Benaya Aritonang Date: Sun, 22 Mar 2026 03:47:48 +0700 Subject: [PATCH] Remove dependency review workflow --- .github/dependency-review-config.yml | 7 ------- .github/workflows/dependency-review.yml | 20 -------------------- CONTRIBUTING.md | 4 ---- README.md | 4 ---- template-playbook.md | 17 +++++++---------- 5 files changed, 7 insertions(+), 45 deletions(-) delete mode 100644 .github/dependency-review-config.yml delete mode 100644 .github/workflows/dependency-review.yml diff --git a/.github/dependency-review-config.yml b/.github/dependency-review-config.yml deleted file mode 100644 index 0610f80..0000000 --- a/.github/dependency-review-config.yml +++ /dev/null @@ -1,7 +0,0 @@ -# Keep the initial policy focused on risky dependency changes first. -# Avoid a strict license allowlist here because it tends to make normal -# Dependabot updates noisy across ecosystems and workflow dependencies. -fail-on-severity: high -fail-on-scopes: - - runtime -license-check: true diff --git a/.github/workflows/dependency-review.yml b/.github/workflows/dependency-review.yml deleted file mode 100644 index b1c90b6..0000000 --- a/.github/workflows/dependency-review.yml +++ /dev/null @@ -1,20 +0,0 @@ -name: Dependency Review - -on: - pull_request: - -permissions: - contents: read - -jobs: - dependency-review: - name: Dependency Review - runs-on: ubuntu-latest - steps: - - name: Checkout - uses: actions/checkout@v4 - - - name: Review dependency changes - uses: actions/dependency-review-action@v4 - with: - config-file: ./.github/dependency-review-config.yml diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ab947f8..80a28b9 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -95,10 +95,6 @@ npm run report:licenses That command writes generated reports into `reports/licenses/`. -Dependency review also runs automatically on pull requests to catch newly introduced vulnerable dependency changes. - -That dependency review config also includes an allowlist for the licenses already present in the current dependency tree. If you intentionally add a dependency under a new acceptable license, update `.github/dependency-review-config.yml` in the same pull request. - ## Changing the API Contract If you modify request or response shapes: diff --git a/README.md b/README.md index 8d46307..be392fc 100644 --- a/README.md +++ b/README.md @@ -123,12 +123,8 @@ The root check runs: CodeQL code scanning also runs on GitHub for `javascript-typescript`, `python`, and workflow files. -Pull requests also run GitHub dependency review so new vulnerable dependency changes are easier to catch before merge. - A separate GitHub workflow generates license-report artifacts for the root workspace, frontend workspace, and backend Python environment. -The dependency-review config also keeps a conservative allowlist of licenses already present in the current dependency tree, so tightening policy does not start by breaking routine updates. - An SBOM workflow also publishes SPDX artifacts for the repository source plus the frontend and backend runner images. ## Releases diff --git a/template-playbook.md b/template-playbook.md index 344eaaf..b895023 100644 --- a/template-playbook.md +++ b/template-playbook.md @@ -68,7 +68,7 @@ Build the second layer early, not after the repo gets messy. - workflow lint - secret scan -- dependency review on pull requests +- optional dependency review on pull requests if it stays low-noise for the repo - license reporting when dependency visibility matters - SBOM generation for source or publishable artifacts when relevant - app verification @@ -292,8 +292,6 @@ Keep: - `scripts/report-licenses.mjs` - `.github/workflows/template-ci.yml` - `.github/workflows/codeql.yml` -- `.github/workflows/dependency-review.yml` -- `.github/dependency-review-config.yml` - `.github/workflows/license-report.yml` - `.github/workflows/sbom.yml` - `SECURITY.md` @@ -302,7 +300,7 @@ What it should cover: - tracked git content scanned with `gitleaks` or equivalent - CodeQL or equivalent static analysis -- dependency review on pull requests +- optional dependency review on pull requests if it behaves cleanly for the dependency ecosystems in the repo - generated license inventories for package ecosystems in the repo - SBOM artifacts for source and release artifacts - private disclosure guidance @@ -317,7 +315,7 @@ Generic takeaway: - secret scanning is a near-default for public repos - CodeQL or equivalent static analysis is a strong baseline for maintained starters -- dependency review gives fast signal before risky packages land +- dependency review can be useful, but it should be kept non-blocking or removed if it creates more noise than signal - non-blocking license reporting is a good bridge before stricter allowlist enforcement - SBOM generation is a strong supply-chain visibility layer for deployable templates @@ -432,9 +430,7 @@ soon.md .github/ISSUE_TEMPLATE/* .github/release-drafter.yml .github/labels.json -.github/dependency-review-config.yml .github/workflows/template-ci.yml -.github/workflows/dependency-review.yml .github/workflows/release-drafter.yml .github/workflows/release.yml .github/workflows/release-smoke.yml @@ -456,6 +452,8 @@ Add these if relevant: scripts/check-contract-drift.mjs scripts/check-docker-builds.mjs scripts/check-release-smoke.mjs +.github/dependency-review-config.yml +.github/workflows/dependency-review.yml docs/assets/* docs/openapi.yaml tests/fixtures/* @@ -498,7 +496,7 @@ For most future non-domain-specific starters, preserve this rough shape: - app, test, and build verification - browser E2E when the product story promises real workflows - platform-specific verification if relevant -- dependency review +- optional dependency review if it is trustworthy for the repo - Docker or packaging check if deployable ### Release Layer @@ -558,7 +556,6 @@ If you want the version that scales better for open source or long-term reuse, a - `LICENSE` - workflow lint - CodeQL -- dependency review - label sync - release drafter - release smoke tests @@ -608,7 +605,7 @@ These patterns are still generic even though the local implementation is CV-shap - repos with real user flows should have at least one browser E2E confidence path - workflows should be linted - secrets should be scanned -- dependency changes should be reviewed on pull requests +- dependency changes should be reviewed on pull requests when the signal is reliable enough to justify the maintenance cost - dependency licenses should be reportable without manual digging - SBOMs should be generated for source trees or release artifacts when supply-chain visibility matters - published artifacts should have provenance attestations when the platform supports them