Every team knows their pipelines should scan for secrets, sign their builds, and protect their main branch. Far fewer can answer the question an auditor actually asks: prove it — for every pipeline, and prove it was true last quarter too. The evidence is scattered across CI settings pages, screenshots in a shared drive, and someone’s memory.
Talarity’s Pipelines page is a per-repository inventory of your build pipelines and their security posture — secret scanning, signed builds, branch protection, required reviews, and SLSA build level — captured as append-only, point-in-time attestations. It is an honest attestation model, not a live scanner: you record the controls you have observed, and every change writes a new dated attestation, so the page always answers both “what is our posture now?” and “can we show how it got there?”
The register at a glance
Open Application Security → Pipelines. Six cards answer the leadership questions immediately: how many pipelines you track, and what share of them have secret scanning enabled, signed builds enforced, branch protection enforced, and a SLSA build level of 2 or higher — plus how many have any SLSA attestation at all. The list below shows one card per pipeline with its platform, repository, and colour-coded posture chips; selecting one opens its full detail on the right.
Coverage percentages are computed from the real stored control states, and they are honest about the unknown: a pipeline you have not yet assessed counts as neither pass nor fail, and a metric with nothing to measure reads ”—”, never a fake zero.
Record a pipeline and only what you’ve observed
Click Add pipeline. Give it a name, pick the platform (GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure DevOps), choose the repository it builds by name — not an internal id — and record the controls you have actually confirmed: secret scanning, signed builds, branch protection, required reviews, and SLSA build level. Anything you leave as unknown is exactly that — the platform never assumes a control is in place.
Recording a pipeline with any control state set writes its first attestation at the same time, so its history starts from day one.
The attestation trail — posture over time, not just today
This is what separates an inventory from an audit record. Every time you update a pipeline’s controls, Talarity appends a new point-in-time attestation rather than overwriting the last one. The result is a dated trail you can hand an auditor: here is exactly when branch protection went from absent to enforced, when signed builds turned on, and when the SLSA level climbed.
The example above tells a real remediation story: across three attestations the build-integrity controls were hardened quarter over quarter — but secret scanning stayed disabled, so the register keeps flagging it. Progress is visible and the outstanding gap is not hidden by it.
Pipeline issues are findings — not a second backlog
A pipeline’s security problems belong in the same register your scanners already feed. Click Link finding and pick an existing finding by title from your AppSec findings register — nothing is tracked twice.
The linked findings then show inline on the pipeline, each with its class, CVSS-graded severity, and status — and a one-click unlink if you correlated the wrong one.
Import an inventory you already have
You do not have to enter pipelines one at a time. Click Import and paste a JSON array exported from your CI provider or a maintained inventory. Each row needs a name and platform; control states default to unknown. Import is idempotent — re-running it skips pipelines that already exist, so you can re-sync safely.
Find the pipelines that matter
A real estate of pipelines needs to narrow fast. Filter by platform to scope a review to one CI system…
…or filter by branch protection to run posture-gap triage — pull every pipeline whose main branch is only partially protected (or not protected at all) in one click.
Re-attest as the posture changes
When a control changes — you turn on secret scanning, raise the SLSA level, enforce required reviews — click Attest posture. The form is pre-filled with the pipeline’s current controls; update what changed and save. Each save appends a new attestation to the history, so the trail stays honest and complete.
What you walk away with
A per-repository pipeline inventory where every security control is an attested, dated fact — not a claim. The coverage cards answer “how hardened is our build estate?” live; the attestation history answers “prove it, and prove it last quarter” without a screenshot hunt; and a pipeline’s real security issues live in the same findings register as everything else your scanners surface.
Posture maps to the standards auditors reference: SLSA v1.0 Build track levels 0–3 (Level 2+ is where build provenance is generated and signed by a hosted build service, making it non-forgeable), branch-protection and required-review change-management controls (SOC 2 CC8.1), secret scanning, and signed-build provenance — the supply-chain integrity practices that Executive Order 14028 put on every software vendor’s roadmap. Talarity is honest about the boundary: this posture is attested, not live-scanned; direct CI-provider sync is a disclosed, in-progress capability.