# Tools Source: https://www.testifysec.com/docs/cilock/tools CI/lock signs any CLI tool's output — SBOMs, SARIF, VEX, container metadata, IaC misconfigs. Wrap the tool with `cilock run` and the output becomes a signed v0.3 attestation parsed by the matching rookery attestor — no `cp` shims, no `bash -c` chains. Wrap any CLI security or supply-chain tool with `cilock run` and the tool's structured output becomes a signed v0.3 attestation. The pattern is the same for every tool — CI/lock invokes the tool as its direct child, captures the output file as a real product in the v0.3 Merkle tree, and the matching rookery attestor parses that captured file. No `cp` shims, no `bash -c` shell wrappers. ## The pattern ```bash cilock run --step \ --signer-file-key-path key.pem \ --outfile attestation.json \ --attestations ,environment,git \ -- -o ``` What lands in the signed envelope: | Predicate | Source | | --- | --- | | `command-run/v0.2` | The literal tool argv + exit code + opened-file traces via the ptrace spy | | `material/v0.3` | Merkle root over the working tree before the tool runs | | `product/v0.3` | Merkle root over files the tool produced (the SARIF, the SBOM, the metadata file) | | Tool-specific | The matching attestor (`sarif`, `sbom`, `vex`, `docker`, `oci`, etc.) parses the captured output and emits its own predicate alongside | Every tool below is **validated end-to-end** in [aflock-ai/attestor-compliance-examples](https://github.com/aflock-ai/attestor-compliance-examples) — the per-tool examples there are the source of truth for the invocations shown on each tool's page. ## Browse by category Tools are grouped using the same ontology DevSecOps teams already use, expanded to cover the full lifecycle: - **SAST** — CodeQL, Semgrep, gosec - **SCA / Vulnerability** — Trivy, Grype, OSV-Scanner, govulncheck - **IaC & Configuration** — Checkov, Hadolint - **Container & Kubernetes** — Kubescape - **SBOM Generation** — Syft - **DAST** — OWASP ZAP, Nuclei - **Cloud Security Posture (CSPM)** — Prowler, Steampipe - **Compliance & Benchmark** — OpenSCAP, InSpec - **TLS & Cryptographic Compliance** — testssl.sh - **Service Mesh & Runtime** — Linkerd, Falco The card grid below shows each supported tool with a one-line description, organized in the same order as the sidebar. [## SAST 3 items](https://www.testifysec.com/docs/cilock/tools/codeql) [## SCA / Vulnerability 4 items](https://www.testifysec.com/docs/cilock/tools/trivy) [## IaC & Configuration 2 items](https://www.testifysec.com/docs/cilock/tools/checkov) [## Container & Kubernetes 3 items](https://www.testifysec.com/docs/cilock/tools/kubescape) [## SBOM Generation 1 item](https://www.testifysec.com/docs/cilock/tools/syft) [## DAST 2 items](https://www.testifysec.com/docs/cilock/tools/zap) [## Cloud Security Posture (CSPM) 2 items](https://www.testifysec.com/docs/cilock/tools/prowler) [## Compliance & Benchmark 2 items](https://www.testifysec.com/docs/cilock/tools/oscap) [## TLS & Cryptographic Compliance 1 item](https://www.testifysec.com/docs/cilock/tools/testssl) ### SAST — Static Application Security Testing Source-code analysis. Pattern matching, dataflow, type inference; every finding lands as SARIF 2.1.0, parsed by the `sarif` attestor. - [**CodeQL**](https://www.testifysec.com/docs/cilock/tools/codeql) — GitHub's static analysis engine (also powers GitHub Advanced Security). Python, Go, JS/TS, Java, Kotlin, C/C++, C#, Ruby, Swift. - [**Semgrep**](https://www.testifysec.com/docs/cilock/tools/semgrep) — multi-language pattern + dataflow SAST with bundled and custom rulesets. - [**gosec**](https://www.testifysec.com/docs/cilock/tools/gosec) — Go-focused SAST flagging the standard G-codes (weak crypto, insecure RNG, command injection, etc.). ### SCA — Software Composition Analysis Match installed packages, lockfiles, or container layers against a vulnerability database. The `sarif` attestor captures SARIF 2.1.0 uniformly; tool-specific attestors are in development to preserve match metadata that flattens into SARIF. - [**Trivy**](https://www.testifysec.com/docs/cilock/tools/trivy) — containers, IaC, secrets, licenses (multi-target). Also covers SCA via `trivy fs`. - [**Grype**](https://www.testifysec.com/docs/cilock/tools/grype) — image or directory vulnerability matching against the Anchore feed; can consume a pre-built SBOM. - [**OSV-Scanner**](https://www.testifysec.com/docs/cilock/tools/osv-scanner) — lockfile + container scanning against the OpenSSF [OSV.dev](https://osv.dev/) database. - [**govulncheck**](https://www.testifysec.com/docs/cilock/tools/govulncheck) — Go-specific scanner with call-graph reachability (flags only the vulns your code actually calls). ### IaC & Configuration Lint Infrastructure-as-Code and container definitions before they're applied. - [**Checkov**](https://www.testifysec.com/docs/cilock/tools/checkov) — Terraform, CloudFormation, Kubernetes, Helm, ARM, Bicep, Dockerfile, and more. - [**Hadolint**](https://www.testifysec.com/docs/cilock/tools/hadolint) — Dockerfile linter with 100+ rules (pinned base images, package install hygiene, USER root). ### Container & Kubernetes Image scanning + live-cluster posture against compliance frameworks (NSA/CISA, MITRE ATT&CK, ArmoBest). - [**Kubescape**](https://www.testifysec.com/docs/cilock/tools/kubescape) — Kubernetes posture scanner. Supports static manifests + cluster-snapshot scans. ### SBOM Generation Software Bill of Materials. The `sbom` attestor parses CycloneDX or SPDX JSON; the emitted predicate type is the SBOM's native URI (`https://cyclonedx.org/bom` or `https://spdx.dev/Document`), not an aflock namespace URI. - [**Syft**](https://www.testifysec.com/docs/cilock/tools/syft) — multi-source SBOM generator (containers, directories, archives, OCI layouts). CycloneDX or SPDX output. ## Categorized by output format | Output format | Tools | Attestor | | --- | --- | --- | | **CycloneDX JSON / SPDX JSON** | Syft | `sbom` (emits `https://cyclonedx.org/bom` or `https://spdx.dev/Document`) | | **SARIF 2.1.0** | Trivy, Grype, OSV-Scanner, govulncheck, Semgrep, gosec, Checkov, Hadolint, Kubescape | `sarif` | | **OpenVEX** | (any VEX-emitting tool — `vexctl`, syft-vex, etc.) | `vex` | | **BuildKit JSON metadata** | docker buildx | `docker` | | **`docker save` tarball** | docker save | `oci` | | **K8s manifest YAML** | `kubectl get` / `kubectl kustomize` | `k8smanifest` | For the full per-attestor reference (predicate types, schema, JSON example) see the [attestor catalog](https://www.testifysec.com/docs/cilock/reference/attestor-catalog). ## Adding a new tool The criteria for inclusion: 1. **Stable machine-readable output flag.** Required. The tool must support a documented `--format` / `-o` / `--output-file` flag producing JSON, SARIF, XML, CycloneDX, or SPDX. 2. **Versioned schema.** The output's structure must be stable (a documented schema URL or a clear major-version commitment). 3. **Open source or free tier.** Commercial-only tools without a free tier are documented but not validated against. 4. **Not redundant with an existing attestor.** Avoid double-coverage — if a tool already flows through `sarif` or `sbom` cleanly, it's "supported-via-existing" and gets a tools page, not a new attestor. See [`CANDIDATE-ATTESTORS.md`](https://github.com/aflock-ai/attestor-compliance-examples/blob/main/CANDIDATE-ATTESTORS.md) for the full evaluation matrix of 35 candidate tools. ## Frequently asked questions ### Does CI/lock support ? If the tool emits SARIF 2.1.0, CycloneDX, SPDX, or OpenVEX — yes, today, via the matching attestor. If the tool emits a stable tool-specific JSON schema, file an issue against rookery to add a native attestor. ### Why must the tool be invoked directly by CI/lock? So `command-run/v0.2` records the tool's real argv, the ptrace spy can trace the tool's syscalls, and `product/v0.3` captures the tool's real output file. A `bash -c "cp tool-output.sarif product.sarif"` shim records `bash` in `command-run`, hides the tool from the spy, and binds an indirect copy as the product — defeating the per-step provenance graph. ### What if the tool exits non-zero on findings? Most security tools do (gosec, hadolint, trivy with `--exit-code`, checkov, etc.). Use the tool's native "soft-fail" flag (`-no-fail`, `-s`, `--exit-code 0`) so CI/lock's `command-run/v0.2` stays green. Enforce the finding-count gate in your policy's Rego over the captured SARIF, not at the tool exit code. ### What if the tool writes its output to stdout, not a file? Wrap with a minimal `sh -c ' ... > out.sarif'`. The `command-run` attestor records the full `sh -c` argv including the tool — that's not the `cp` antipattern, it's a single shell redirect routing the tool's output to a file the product attestor can hash. govulncheck, hadolint, and kubectl all need this. ### Can I use the same pattern in CI? Yes — every tool page shows the raw CI/lock invocation; the [GitHub Actions](https://www.testifysec.com/docs/cilock/tutorials/github-actions-pipeline) and [GitLab CI](https://www.testifysec.com/docs/cilock/tutorials/gitlab-ci-pipeline) tutorials translate it to the cilock-action / cilock-runner shapes. Each scan/build step becomes its own discrete `cilock` run; the release-gate Rego ties them together via `attestationsFrom` + the v0.3 Merkle root binding. ## See also - [Attestor catalog](https://www.testifysec.com/docs/cilock/reference/attestor-catalog) — every attestor, its predicate type URI, and lifecycle phase - [The spine of the graph](https://www.testifysec.com/docs/cilock/concepts/the-spine-of-the-graph) — how subject digests link captures across steps - [Verify a specific file](https://www.testifysec.com/docs/cilock/guides/verify-a-specific-file) — consumer-side inclusion-proof flow - [`aflock-ai/attestor-compliance-examples`](https://github.com/aflock-ai/attestor-compliance-examples) — every validated tool example, end-to-end Reference generated from the product documentation. Match commands and support details to your installed release.