Customers Tighten DevSecOps: Contractors Are Checked at Every Step of the Build

In December 2020, the trojanized SolarWinds Orion update reached roughly 18,000 of the company's customers. The incident reminded the industry that the vulnerable part may not be the product itself, but the path it takes to the customer. The Russian market is reaching the same conclusion. According to TAdviser, customers are moving deeper into zero trust toward IT contractors and demanding a "sterile pipeline" for development, with repeated code checks. The approach rests on DevSecOps, a software development lifecycle in which security is built into every stage rather than added before release.

Where the distrust comes from

The classic model was simple. The contractor writes the code and hands over a build, and the customer runs acceptance testing. Everything that happens inside the contractor stays a black box. But a contractor means developers' laptops, third-party libraries, cloud repositories and CI systems, and every one of these can be compromised.

The examples are well known. The Log4Shell vulnerability in late 2021 showed how a single logging library can end up in thousands of products whose owners do not even know it is there. The backdoor in the XZ Utils archiver (CVE-2024-3094), discovered in 2024, was planted through long-running social engineering of the project's maintainer. The zero-trust principle, formalized in NIST SP 800-207, calls for verifying every participant and every action. Now it is being applied to development.

What a "sterile pipeline" looks like

TAdviser describes a trend, not a single standard, so the set of measures differs from customer to customer. A typical setup looks like this:

• an isolated build environment with no internet access and a limited set of external dependencies;
• static code analysis (SAST) on every commit and dynamic analysis (DAST) on test environments;
• software composition analysis (SCA): an inventory of third-party components and a search for known vulnerabilities;
• an SBOM, a list of all build components, as a mandatory delivery artifact;
• scanning repositories for secrets: keys, tokens, passwords;
• mandatory code review by a second person and signing of built artifacts;
• repeated checks of the source code and build on the customer's side.

The key word here is "repeated." The same code is analyzed at the contractor, then at the customer, and sometimes by an independent lab as well. Each layer catches what the previous one missed. Each also assumes that the previous one may have been compromised.

The cost for contractors

For contractors, this means higher costs and reworked processes. They need dedicated build environments, licenses for analysis tools, secure-development specialists and a level of discipline that small teams often lack. Mature integrators that already have DevSecOps built into production come out ahead. Smaller studios will have to either catch up or move to segments with less stringent requirements.

There is a downside, too. Repeated checks slow down releases, and some analyzer findings turn out to be false positives that become noise if no one triages them. A customer that overdoes the control pays for it in timelines.

Where to start

Customers should write secure-development requirements into the contract: the SBOM format, scanning frequency, audit rights and the procedure for responding to discovered vulnerabilities. It makes sense to sort contractors by the criticality of the systems involved rather than apply maximum control everywhere in the same way.

Contractors can start small: add secret and dependency scanning to the existing CI, make code review mandatory and learn to generate SBOMs automatically. These steps are cheaper than the rest and immediately answer auditors' main questions. Those who prepare before the requirement appears in a tender will have an advantage over those who start afterward.