# Offline containers and Drone pipelines

The default templates use one image per tool. See
[PER-TOOL-CONTAINERS.md](PER-TOOL-CONTAINERS.md) for the archive/tag table, load
commands, full offline acceptance tests and rebuild procedure. The combined
scanner image is retained for compatibility.

Each individual image has a shell for Drone. Gitleaks, Trivy, Syft and Grype
have separate source steps; Syft writes SBOMs to the shared evidence volume and
Grype reads them in the following step. Artifact scanning follows the same
pattern. ZAP runs from its existing standalone archive. Native exec runners
continue to use `examples/drone-exec.yml`.

## Enable your existing Drone integration

1. Load each tool image on every runner and use `localhost/devsecops/TOOL:VERSION`
   with `pull: never`, or publish to your approved internal registry and pin its
   approved digest in all templates. Mirror Drone clone/build/plugin images too.
2. Run `drone/selftest.yml` in a disposable repository first.
3. Merge `drone/source.yml` into the application pipeline. It scans complete Git
   history/files with Gitleaks, runs Trivy, and generates Syft SBOMs for Grype.
   Reports live outside the checkout; both scanner paths run even if one fails.
4. Adapt `drone/release.yml` for protected tags. Replace every example registry,
   staging URL and evidence endpoint, and supply the project hooks below.
5. Require passing Drone statuses and reviews in Gitea branch protection.
   Restrict pipeline changes, tag creation and promotion credentials. Never
   provide production credentials to untrusted pull requests.

The templates are integration scaffolding: missing hooks fail the pipeline.
They do not install or configure Jira, Drone, SonarQube or openQA servers.

| Required project hook | Contract |
|---|---|
| `ci/build.sh OUTPUT_ARCHIVE` | Build once, save the application Docker archive, return nonzero on failure |
| `ci/sonarqube-gate.sh` | Submit analysis and wait for the final quality/security gate; fail on errors, timeout or a rejected gate |
| `ci/deploy-staging.sh ARCHIVE` | Deploy the exact scanned candidate to isolated staging and wait for readiness |
| `ci/openqa-gate.sh` | Run system/functional/regression tests for this build and wait for the final result |
| `ci/verify-and-promote.sh RELEASE_DIR` | Check `release.sha256`, promote `app.tar` without rebuilding, and record the build identity |
| `ci/jira-feedback.sh REPORT_DIR` | Convert reports/build status into deduplicated Jira findings using your existing integration |

The default release sequence is source gates → build/SonarQube → image gates
→ staging/openQA → ZAP → prepare/check release → promote → evidence/Jira feedback.
Both source and image gates use separate Syft, Grype and Trivy steps.
Syft writes the SBOM to the evidence volume; Grype consumes that exact file. For RPM-only applications,
replace the image build/scan/deploy steps with your RPM workflow, generate a Syft
inventory of installed contents, and omit ZAP if there is no HTTP service.
The optional combined image's `ci-security host` adapter and `containers/Containerfile.openscap-rhel`
remain optional extensions; use genuine RHEL media and entitled RPMs.

Evidence collection and Jira feedback run on success or failure. Store reports
from application hooks under `/security` (mounted for build and test hooks).
Use the `security_evidence_token` Drone secret for the configured HTTPS artifact
endpoint; Jira credentials belong to your organization's feedback hook and must
be restricted to trusted events. No credentials are embedded in the bundle.

Record Jira project, component/version, CVE/rule, severity, commit/build, evidence
link, owner, due date and exception expiry. Deduplicate by project + component +
CVE/rule. Scheduled source rescans use `drone/source.yml`'s cron trigger; schedule
artifact and staging rescans separately for deployed versions.

## Release integrity

`evidence-tools package ARCHIVE SBOM NEW_DIRECTORY` copies the candidate and SBOM
and generates `release.sha256`. `evidence-tools verify DIRECTORY` checks exactly
those two files. The directory must be new. SHA256 provides integrity checks,
not producer authentication. The deploy hook must recheck immediately before
promotion, using controlled release storage and the successful gate records.