본문으로 건너뛰기
cccskills
무료GitHub에 공개

syft-generation

Generates, scans, and diffs Software Bills of Materials (SBOMs) with the Anchore stack - Syft generation from container images / directories / archives across OCI / Docker / Singularity formats (output CycloneDX-JSON / SPDX-JSON / Syft-JSON / table / GitHub-JSON, cosign attestation); the paired generate + scan workflow with Grype (`grype sbom:./sbom.json`, `--fail-on high`, `--only-fixed`, `.grype.yaml` ignore rules with mandatory `expires:`, EPSS/KEV prioritization); and SBOM-to-SBOM diffing via `cyclonedx diff --component-versions` to gate CI on net-new components and detect supply-chain drift between builds. Use when the team needs SBOM artifacts for compliance (US EO 14028, EU CRA, FDA medical-device guidance), SBOM-driven vulnerability scanning, or dependency-drift detection between releases.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

testland/qa스타 13(GitHub 13 + cccskills 0)
연동 도구GitHubDocker

실행 점수 미검증

설치 방법 보기

포함된 파일(5)

  • SKILL.md14.2 KB
  • .tessl-plugin/plugin.json940 B
  • references/diff-ci-workflows.md2.4 KB
  • references/formats.md1.4 KB
  • references/grype-ignore-rules.md1.4 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

syft-generation

Overview

Per github.com/anchore/syft, Syft generates SBOMs from "container images, filesystems, archives" (OCI, Docker, Singularity). The SBOM is the input artifact for vuln scanning with Grype (Step 7), for SBOM-to-SBOM drift diffing (Step 8), and for compliance delivery in SPDX or CycloneDX format.

SBOMs are mandated by US EO 14028 (software sold to federal agencies), the EU Cyber Resilience Act (products with digital elements, in effect 2024+), and FDA medical-device guidance; internal supply-chain audits also need a full dependency manifest.

When to use

  • The team ships software to customers requiring an SBOM (federal, EU regulated, medical device, etc.).
  • Internal compliance program requires SBOM as evidence artifact.
  • The vuln-scanning workflow needs an SBOM input (Grype, OSV-Scanner with --sbom).
  • Container-image build pipelines need accompanying SBOM for delivery alongside the image.
  • A rebuilt image needs a dependency-drift check ("what changed in the inventory?") or a "no unexpected new transitive deps" release gate (Step 8).

Step 1 - Install

Per sf-gh:

# Homebrew
brew install syft

# Docker
docker run --rm -v "$PWD:/scan" anchore/syft scan dir:/scan -o cyclonedx-json

# Install script into a user-owned dir (-b sets the target; no sudo needed)
curl -sSfL https://get.anchore.io/syft | sh -s -- -b "$HOME/.local/bin"

Other paths (consult sf-gh): Scoop, Chocolatey, Nix.

Step 2 - Basic SBOM generation

Per sf-gh:

# Container image
syft alpine:latest

# Local directory
syft ./my-project

# Specific output format to stdout
syft <image> -o cyclonedx-json

# Multiple formats to files in one pass
syft <image> -o spdx-json=./spdx.json -o cyclonedx-json=./cdx.json

The default output is the table format (human-readable); use explicit -o for machine-readable formats in CI.

Step 3 - Output format catalog

Per sf-gh, the common formats are cyclonedx-json (CycloneDX 1.5+, broad support), spdx-json (SPDX 2.3, preferred by US federal procurement), and syft-json (richest metadata). For Grype scan input (Step 7) use syft-json or cyclonedx-json; for compliance delivery the consumer dictates (SPDX-JSON US federal, CycloneDX-JSON most EU) - see sbom-formats for the format-choice guidance. The full format catalog is in references/formats.md.

Step 4 - Source types

Per sf-gh, the common sources are a local Docker image (syft alpine:latest), a remote registry (syft registry:docker.io/alpine:latest), an archive (syft oci-archive:./image.tar), and a directory (syft dir:./my-project). The full source-type syntax table is in references/formats.md.

Step 5 - Attestation pattern (cosign)

For supply-chain integrity, attach the SBOM to the container image via Sigstore cosign:

# Generate SBOM
syft my-image:1.0 -o cyclonedx-json=sbom.json

# Sign + attach to image (Sigstore)
cosign attest --predicate sbom.json --type cyclonedx my-image:1.0

# Verify
cosign verify-attestation --type cyclonedx my-image:1.0

The attestation lives alongside the image in the registry; downstream consumers can verify provenance + retrieve the SBOM.

Step 6 - False-positive triage analogue

Syft generates inventories, not findings - there's no FP triage per se. The analogue here is inventory accuracy: ensuring Syft correctly identifies all components.

MechanismUse
--exclude=PATH_PATTERNSkip directories from scan (vendor / generated)
--catalogers=CATALOGERRestrict to specific catalogers (e.g., npm, python)
--source-name=NAME / --source-version=VERSIONOverride SBOM-level metadata
--platform=linux/amd64Target specific platform for multi-arch images

Inventory accuracy validation:

# Compare two SBOMs (e.g., before vs after a build change)
syft image:1.0 -o syft-json=v1-sbom.json
syft image:1.1 -o syft-json=v1.1-sbom.json
diff <(jq -S . v1-sbom.json) <(jq -S . v1.1-sbom.json)

If Syft misses a component (false negative on inventory), the downstream vuln scan misses any CVEs against that component. Periodic accuracy validation against known dependencies catches this.

Step 7 - Generate + scan workflow (Grype)

Grype is the Anchore vuln scanner that pairs with Syft. Per github.com/anchore/grype, three input modes:

Input modeUse
Container imagegrype alpine:latest (Grype generates SBOM internally)
Directorygrype ./my-project (filesystem scan)
SBOM inputgrype sbom:./sbom.json (no re-generation; faster + auditable)

The SBOM-input mode is the recommended production pattern: generate the SBOM once via Syft (Step 2), attest via cosign (Step 5), then scan the SBOM. Decoupling gives an audit trail and allows re-scanning with a refreshed vuln DB without re-building. Per gr-gh, coverage spans major OS package ecosystems (Alpine, Debian, Ubuntu, RHEL, Amazon Linux) and language packages (Ruby, Java, JavaScript, Python, .NET, Go, PHP, Rust).

# Install (Homebrew, or the install script into a user-owned dir - no sudo)
brew install grype
# curl -sSfL https://get.anchore.io/grype | sh -s -- -b "$HOME/.local/bin"

# Scan the Syft-generated SBOM (recommended)
grype sbom:./sbom.json

# Output formats: table (default) / json / sarif / cyclonedx-json / template
grype sbom:./sbom.json -o sarif       # GitHub Code Scanning
grype sbom:./sbom.json -o json        # EPSS + KEV + risk-score annotations

# CI gate: exit 1 at/above severity; focus on upgradable findings
grype sbom:./sbom.json --fail-on high --only-fixed

Severity levels per gr-gh: critical, high, medium, low, negligible, unknown. The JSON output annotates findings with EPSS, KEV, and risk scoring for downstream prioritization.

Suppression (MANDATORY triage): Grype's native path is .grype.yaml ignore rules - per-CVE, per-package+version, or pattern-based (fix-state), each with a mandatory expires: date and a reachability reason:. Full config + justification template: references/grype-ignore-rules.md. OpenVEX status assertions (not_affected / fixed / etc., see vex-author) filter findings in a signed, machine-readable way. Audit ignore entries quarterly; expired entries are removed.

DB management for CI determinism - Grype's DB updates multiple times per day; pin per scan or results vary run to run:

grype db update                                # manual refresh
grype db status
grype db import grype-db-v6-2026-05-06.tar.gz  # pinned version for CI

CI wiring - anchore/scan-action wraps Grype + SARIF upload:

      - uses: anchore/scan-action@v5
        with:
          sbom: sbom.cyclonedx.json
          fail-build: true
          severity-cutoff: high
          output-format: sarif
      - uses: github/codeql-action/upload-sarif@v3
        if: always()
        with: { sarif_file: results.sarif }

Grype's DB is Anchore-curated; coverage differs from OSV.dev / Snyk / NVD - pair with osv-scanner or snyk-test for consensus. No reachability analysis: every CVE on a declared component counts.

Step 8 - Diffing SBOMs across versions

An SBOM diff turns two point-in-time inventories into a change signal: which components are net-new, removed, or version-changed between image or build versions. Per github.com/CycloneDX/cyclonedx-cli, the CycloneDX CLI provides a first-class diff subcommand accepting any two CycloneDX BOMs (XML, JSON, or Protobuf):

# Install: brew install cyclonedx/cyclonedx/cyclonedx-cli
#   or:    docker run cyclonedx/cyclonedx-cli ...

# Generate both inventories with the SAME source type + format
syft myapp:1.0 -o cyclonedx-json=sbom-v1.0.json
syft myapp:1.1 -o cyclonedx-json=sbom-v1.1.json

# Human-readable diff
cyclonedx diff sbom-v1.0.json sbom-v1.1.json --component-versions

# Machine-readable diff for CI gate logic
cyclonedx diff sbom-v1.0.json sbom-v1.1.json \
  --component-versions --output-format json > diff-result.json

Key flags per cdx-cli-gh: --component-versions (the signal flag - reports added / removed / version-changed components; without it only structural BOM changes are reported), --from-format / --to-format (autodetect / json / xml / protobuf), --output-format (text / json).

The JSON output carries three lists: added (net-new deps - review every entry: expected transitive dep, base-image update, or supply-chain risk), removed (may hide a dep renamed by a packaging change), and modified (version changes with old + new values). Minimal CI gate:

ADDED=$(jq '.added | length' diff-result.json)
if [ "$ADDED" -gt "0" ]; then
  echo "::error::Net-new components detected. Review diff-result.json."
  jq '.added' diff-result.json
  exit 1
fi

The full GitHub Actions gate with allowlist-subtraction, plus the nightly-drift workflow (diff production tag vs last known-good SBOM, rotate the baseline only on a clean diff), are in references/diff-ci-workflows.md.

Diff rules of thumb: always pass --component-versions; generate both SBOMs with the same tool, format, and source type (dir: vs image scope mismatch produces noisy diffs); diff multi-arch images per-platform (--platform=linux/amd64 on both runs); SPDX SBOMs need cyclonedx convert first. The diff shows inventory change, not vulnerability change - scan net-new components with Grype (Step 7).

Step 9 - CI integration

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: anchore/sbom-action@v0
        with:
          path: ./
          format: cyclonedx-json
          output-file: sbom.cyclonedx.json
      - uses: anchore/sbom-action@v0
        with:
          path: ./
          format: spdx-json
          output-file: sbom.spdx.json
      - uses: actions/upload-artifact@v4
        with:
          name: sboms
          path: sbom.*.json

The anchore/sbom-action GHA wraps Syft + handles GitHub dependency-graph submission automatically when format: github-json.

Step 10 - Composition with sister tools

Sister toolUse
sbom-formatsReference for CycloneDX + SPDX schemas and format choice
trivy-imageAlternative scanner (built-in SBOM gen + scan in one pass)
vex-authorOpenVEX documents that filter Grype findings (Step 7)
osv-scannerCross-plugin: also accepts SBOM input

Anti-patterns

Anti-patternWhy it failsFix
Generate SBOM only at release timeMisses build-time inventory differencesGenerate per CI build + attest
Use single format onlyDifferent consumers need different formatsGenerate both CycloneDX + SPDX (Step 2)
Skip platform targeting on multi-arch imagesMisses platform-specific deps--platform=linux/amd64 (Step 6)
Generate SBOM but don't attest / signProvenance unverifiable downstreamCosign attest pattern (Step 5)
Trust Syft inventory without validationMisses components → misses CVEsPeriodic accuracy check (Step 6)
Re-generate SBOM via Grype on every scanSlow + non-deterministic; SBOM lives outside scanUse sbom: input mode (Step 7)
.grype.yaml ignore without expires:Permanent debtMandatory expires: (Step 7)
Skip Grype DB pin in CIDifferent DB version per run; non-deterministicPin DB version (Step 7)
Diff without --component-versionsReports only structural BOM changes, not inventory deltaAlways pass the flag (Step 8)
Diff SBOMs from different tools / scan depthsFormat + scope mismatches appear as false diffsSame generator, format, source type (Step 8)

Limitations

  • Syft can't scan what it can't see - encrypted archives, custom package formats may produce incomplete SBOMs.
  • Some language-specific catalogers have edge cases (e.g., npm workspaces, Python wheel quirks); validate against known deps.
  • SBOM generation alone doesn't prove the deps are vulnerability-free - run the Grype scan step (Step 7).
  • Multi-arch container scanning is per-platform; combine SBOMs manually or via tooling for unified view.
  • Grype includes no reachability analysis, and its DB coverage differs from OSV.dev / Snyk / NVD (Step 7).
  • cyclonedx diff operates on CycloneDX only; SPDX SBOMs require cyclonedx convert first (Step 8).

References

  • sf-gh - Syft repository: install, scan commands, formats
  • gr-gh - Grype repository: install, input modes, --fail-on
  • cdx-cli-gh - cyclonedx-cli repository: diff flags + output
  • references/formats.md - full output format catalog + source-type syntax
  • references/grype-ignore-rules.md - .grype.yaml config + justification template
  • references/diff-ci-workflows.md - diff CI gate + nightly drift workflows
  • anchore.com/syft - landing
  • oss.anchore.com/docs/reference/grype/cli/ - full Grype CLI reference
  • openvex.dev - OpenVEX specification; first.org/epss - EPSS data source
  • ntia.gov/SBOM - NTIA SBOM minimum elements
  • whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ - US EO 14028
  • sbom-formats, trivy-image, vex-author - sister tools

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Builds a CI gate that fails the build on **new** WCAG / a11y violations introduced by a PR while grandfathering pre-existing violations on a per-rule / per-page baseline. Aggregates verdicts from axe-core / pa11y / Lighthouse a11y / WAVE / IBM Equal Access scans. Use when a project has accumulated a11y debt and a strict "zero violations" gate would block every PR - the ratchet pattern lets the team ship while preventing regressions.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

testland/qa132026년 10월 20일 업데이트

Workflow skill that builds an A/B-test validity checklist from an experiment proposal, walking the canonical design-correctness gates - pre-registered OEC/power/guardrails, randomization unit + SRM check, assignment integrity, telemetry, peeking discipline, novelty/primacy, post-experiment SRM re-check - into a per-experiment checklist + sign-off form. Use when launching, auditing, or governing an experiment. For pitfall mechanics (guardrails, peeking) see experiment-results-interpreter's references; to read an already-valid result use experiment-results-interpreter; for per-SDK harness tests use experiment-sdk-testing - this gates DESIGN, not SDK code.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

testland/qa132026년 10월 20일 업데이트

The single install-flow skill: the reference contract for the PWA install flow (installability gate fields, `beforeinstallprompt` handshake, per-platform paths - Android WebAPK / iOS Share menu / Firefox no-op - and the `display-mode` post-install signal, in references/install-flow-reference.md) plus the build-an-X workflow that emits the Add-to-Home-Screen suite. Walks the four-stage timeline, emitting one test per gate cell per [web.dev/articles/install-criteria][install-criteria], the deferred-prompt → `prompt()` → `userChoice` chain per [web.dev/articles/customize-install][customize-install], the iOS Safari manual-metadata branch (`apple-touch-icon`) per [web.dev/learn/pwa/installation][learn-pwa], and the post-install `(display-mode: standalone)` MQ assertion. Output: a Playwright spec with per-stage cells plus a coverage matrix. Use when a PWA's manifest, icons, or install handler change, when install conversion drops at an unknown stage, or when triaging a flaky install assertion.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

testland/qa132026년 10월 20일 업데이트

Build-an-X workflow that uses an LLM to map existing tests to spec sections - given a spec doc + the test suite, the LLM identifies which tests cover which sections, surfaces uncovered sections (gap), and recommends specific tests to add. Output is a coverage matrix per spec ID. Scope is mapping tests that already exist and naming the gaps, not authoring tests for new acceptance criteria. Use when a spec doc and a test suite both exist but nobody can say which requirements are actually covered - before a release sign-off, an audit, or a decision about where to spend the next round of test effort.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

testland/qa132026년 10월 20일 업데이트

Generates tests from natural-language specs (acceptance criteria, user stories, requirements) using an LLM, with confidence scoring per test case (LLM self-assessment plus heuristics: assertion quality, naming, completeness), batching uncertain cases for human review, and integration with the team's existing test framework. Use when the user asks to generate unit tests from acceptance criteria, convert user stories to test cases, automate test creation from requirements, or augment a spec-driven test suite with AI-generated stubs that are then curated before merge.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

testland/qa132026년 10월 20일 업데이트

Configures Allure Report (test-runner adapter install, `allure-results` directory wiring, `categories.json` for failure classification, `history-trend.json` retention via the copy-history-between-runs pattern), runs the Allure CLI to convert `allure-results` to a static HTML site, and uploads the report as a CI artifact. Use when the team needs richer test reporting than JUnit XML - step-level attachments, per-test history, retry tracking, and severity / epic / feature labeling across framework-agnostic adapters (pytest, Jest, JUnit, TestNG, NUnit, Mocha). As a rich static HTML report generator, it is the open-source alternative to the sunset ExtentReports (JVM/.NET per-test HTML narrative); for hosted cross-run flakiness analytics rather than a static per-run report use currents-integration.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

testland/qa132026년 10월 20일 업데이트

testland의 스킬 모두 보기

이 스킬의 문제 신고