Secure the pipeline that ships your code.

Most security programmes put their effort into the code: scanners on the repository, reviews on the pull request, tests before release. That work matters. But the code does not deploy itself. A build server, a set of pipeline definitions, a handful of service accounts and hundreds of third-party packages sit between a developer's commit and your customers. Each of those is trusted to do exactly what it should, and each is a place where something else can be slipped in.

The questions a board, a regulator or a customer's security team ask are simple to state and hard to answer. They want the number of pipelines that can reach production, and which of them are checked against which rules. They want to know whether last Tuesday's build passed those rules, which open-source components went into it and whether any carry a known critical vulnerability. They also want to know who may run security scans on the payments pipeline, and who granted that right.

In many organisations the honest answer is a mix of tribal knowledge and spreadsheets. Pipelines get created by teams who have since moved on. A gate that was meant to block on critical findings was switched off during an incident and never switched back. A dashboard shows green because a check did not run, and a check that did not run looks the same as one that passed.

Pipeline security in Aribot is built around closing those gaps with records you can show: every pipeline your connectors can see, an explicit decision on whether it is in scope, the rules each build must meet, a verdict per run that never pretends, a bill of materials per scan with a risk score you can explain, and a list of who may run what. It sits next to code security, and both report on the same pull request. See code review for the other half.

A gate policy is a rule your company sets for its pipelines: block the build if there is any critical finding, require a bill of materials, stop when high-severity findings pass a threshold. Having the rule written down says nothing about whether any build met it. That is why Aribot shows two different things on two different parts of the screen.

The first is the list of configured gate policies, by name and type. The second is each scan's verdict: for a chosen run, which checks passed, which failed, the value measured and the threshold it was held to. When a check was not evaluated, the verdict says exactly that. When nothing at all was evaluated on a run, the screen says no verdict was recorded. Neither is ever drawn as a green tick.

This sounds like a small design choice. In practice it is the difference between a dashboard you can trust in an audit and one you have to explain. It also keeps teams honest with themselves: a pipeline whose gates never ran shows up as a gap to fix. Pipeline gate results sit alongside your other frameworks in the compliance view, so the people who report on controls see them in the same place.

Every pipeline scan produces a software bill of materials: the components in the build, their versions and types, the licences they declare, and the vulnerabilities found in them. Most of the risk in a modern application is not in the packages a team chose but in the packages those packages chose. The bill of materials shows both, and counts vulnerabilities per component so you can see where they cluster.

Next to it sits a risk assessment for the scan: a score from 0 to 100 where higher is worse, a risk level, a breakdown by dimension and the top contributing factors. The factors are the useful part. “High risk” on its own starts a meeting; “a critical vulnerability in a transitive image library, and a component with no declared licence” starts a fix.

Aribot does not guess when it cannot read. If a scan's bill of materials could not be read, the screen says so and shows no estimate. If a build has no components, it shows “no components”, which is a different statement from “no risk”. A gate can require that a bill of materials exists, so a pipeline that stops producing one is stopped.

Security scans read source code, configuration and sometimes secrets in transit. The right to run them is worth controlling, and the right to see their results even more so. In Aribot, access to an approved pipeline is granted per member and per pipeline, in one of three roles: admin, scanner or viewer.

The grants screen is a plain table: member, pipeline, role, who granted it and when. It is the table an access review needs. Only members with a grant for that pipeline can scan it. Company owners can reach every pipeline and are not listed, and the screen states this so nobody wonders why a name is missing.

The flow starts earlier, with discovery. Connectors find pipelines in your source control. Each arrives as available or pending review, and an admin approves it into scope or rejects it. Only approved pipelines can be granted and scanned, so a repository nobody has looked at cannot become a scanning target by accident.

Pipeline security and code security answer different questions, and it helps to be clear about which is which. Code security looks inside the change: insecure patterns, secrets, vulnerable dependencies, and whether the threats in your threat model are mitigated by the code. Pipeline security looks at the road the change travels: whether the pipeline is in scope, whether the build met its gates, what the artefact contains and who could trigger it.

They meet on the pull request. The code review comment tells the developer what the change does to security, line by line. The pipeline gate decides whether the change may proceed. Because both read from the same threat model and the same scan, the developer is not given two contradicting answers.