Every piece of software running in production answers a question, whether anyone asked it or not: who said this could run, and on what evidence? For most organizations today the answer is a dashboard, a ticket that was closed, or a pipeline that went green. Nobody's name is on it.
At Ulap we built CYBO Attest so the answer is a person. Every container build is verified, every finding is explained in plain language, and every release is approved by a named individual who understood the case and has the evidence attached. Here is what that means, why the tools most teams already own stop one step short, and why putting a person on the decision makes it faster, not slower.
The problem nobody plans for
Software is increasingly written by AI, and the people using it will tell you they do not fully trust it. In New Relic's 2026 AI Code Report (June 2026), 82 percent of US technology decision makers said more than half of their weekly code output is now AI driven, and 62 percent said their teams often ship AI generated code without manual verification. In the Stack Overflow Developer Survey (October 2026, more than 30,000 respondents), 73 percent of developers said they use an AI assistant or agent daily, and 93 percent said trusting its output requires source attribution. The people closest to the code want evidence before they trust it, and most organizations are shipping without it.
At the same time the models that write code have learned to find flaws in it. In April 2026 frontier models gained autonomous vulnerability discovery, and within four months high and critical severity CVE disclosures across 21 notable software organizations reached about five times the previous monthly record of 494: 1,549 in June, 2,512 in July, and about 2,900 in August (Epoch AI, cyber vulnerability reports, monthly totals through August 2026).
The review process did not change to meet either shift. In defense, an Authority to Operate still takes twelve to eighteen months (Atlantic Council, June 2025). In May 2025 the DoD CIO said she was "blowing up" the Risk Management Framework, and in September 2025 the Cybersecurity Risk Management Construct replaced it with a five phase lifecycle aimed at a constant authorization posture, with a backlog of more than 500 legacy RMF systems to migrate. On the commercial side, IBM's Cost of a Data Breach 2025 found that one in five organizations had already suffered a breach tied to unsanctioned AI tools, that those breaches cost $670K more on average, and that 97 percent of them lacked AI access controls. Of roughly $240B spent on security worldwide, Gartner puts the share going to securing the use of AI at about $2.8B, a little over one percent.
More code, written faster, reviewed less, into a world with five times the known flaws, with a review process built for a different decade. That is the gap.
Four categories, and why none of them decides
Most teams already own tools around this problem, and they are good at what they do. They fall into four categories, each with its own budget line and its own place in the pipeline.
1. AI code review. Reviews the pull request before it merges: comments, suggested fixes, style and logic checks, priced per seat. It is strong before the merge and silent after it. It reads the diff, not the artifact that gets built and deployed, and it never produces an approval by name, a record of accepted risk, or a view across the organization.
2. Application security testing. The scanners: static analysis of the code, dependency and container scanning, secrets detection, infrastructure as code checks, and dynamic testing of the running application. They find what is in the build and hand you a list. They are also a supply chain risk of their own, as the March 2026 compromise of a widely used open source scanner's release pipeline showed, which trojanized nearly every published version and left every team that ran it asking where its scanner came from.
3. Application security posture management. Takes the lists from many scanners across every repository, deduplicates them, correlates them, and ranks them: a risk score per application, a priority order, an SLA clock. Gartner expects 80 percent of regulated organizations using application security testing to adopt one by 2027. It ends at a score, an SLA state, or an exception. Never an authorization.
4. Compliance automation. Collects evidence by integration, drafts policies and control narratives, and readies the audit; in defense, assembles the ATO package and maps the controls. It documents a decision after someone else made it, and nothing in it verifies the build the decision was about.
Find, rank, host, document. Each leaves you with a list, a score, or a report. None of them ends with a decision: a named person, looking at evidence, saying this build is cleared and here is why. That is the one thing an auditor, an assessor, or your largest customer's security team is actually asking you to produce, and it is the step none of these categories performs. The market noticed the platforms and not the gap: the largest security acquisition on record closed in March 2026, and the posture category is consolidating around a few platform vendors. Nobody has built the decision.
The gap, in detail
Walk through what happens after the scanners run on a typical build, because the gap is easy to describe in the abstract and uncomfortable to look at up close.
The build comes back with, say, nineteen static analysis findings, one medium CVE in a base image package, two alerts from the dynamic scan, and a failed job nobody has looked at. Every one of those is now sitting in a different place: the static findings in the scanner's own report, the CVE in the vulnerability tool, the dynamic alerts in a third tool's output, the failed job in the pipeline log. The posture platform has pulled them into one list and sorted them by severity. That is where the tooling stops, and where the questions start.
Which of these must be fixed before this build can run, and which may be accepted? Who decides that, and against what policy? For the ones being accepted, what is the reason, is it a good reason, and who is putting their name to it? For the ones being fixed, what is the fix, and did it work? When the build is finally cleared, what exactly did the person clearing it look at? And six months from now, when an auditor, a customer's security team, or an authorizing official asks why this version was allowed to run with that CVE in it, can anyone produce the answer?
In most organizations the honest answers are: it depends on who is on call; a ticket, if someone opened one; a comment in a pull request or a message in a channel; whatever the engineer remembered to write down; and no. The approval that does exist lives on the merge, which covers the code and not the artifact that was actually built from it. The risk acceptance lives in a conversation. The evidence lives in a dozen pipeline jobs that nobody wrote for a human reader. Nothing ties the decision to the person, the evidence, and the build at the same time, so nothing can be reconstructed later without hours of digging, and often not even then.
That is the gap. Not a missing scanner, a missing step: the moment where a specific person looks at a specific build, understands what was found and what was done about it, accepts what remains under their own name, and leaves a record that can be checked. In defense that step has a name, an authorization, and a process built around it that takes months. In commercial software it mostly has no name at all, which is why it mostly does not happen.
What Attest is
CYBO Attest is the layer that performs that step, on every container build, and the console that puts it in front of the three people who need it.
It sits on top of your existing pipeline. The pipeline builds the container and runs the scanners; Attest reads what they produce. It evaluates a fixed gate policy against the results, so the question of what must be fixed and what may be accepted is answered the same way every time, by code, before anyone opens the list. It then writes a plain language explanation for every gate and every finding, grounded in the scan record, and organizes all of it by application instead of by pipeline job, mapped to the controls it satisfies.
From there it gives each person their own view. The developer sees a worklist: what is blocking this build, in order, with the explanation and the fix for each item, and a drafted justification for anything that cannot be fixed. The reviewer sees a queue: one complete package at a time, every finding with its fix or its justification, the evidence behind it, and the lineage from commit to decision. The risk owner sees posture: every application, worst first, with what is authorized, what is blocked and why, what risk was accepted and by whom, and how long authorization takes. When the reviewer approves, they do it under their own identity, and the decision, the basis, the evidence hash, and the time stay together on the record.
It runs hosted, with early access open now, or inside your own boundary for programs that require it.
What an authorization has to be
To be worth anything, the decision Attest produces has to meet five criteria.
- It verifies the artifact, not the diff. The built container, through a pipeline that runs seven scanners and twelve checks on every build: secret detection (TruffleHog), static analysis (Semgrep), vulnerability and SBOM scanning (Syft and Grype), malware scanning (ClamAV), Dockerfile linting (Hadolint), container rules (approved base image, non root user), and a dynamic scan of the running container (OWASP ZAP). What ships is what gets checked.
- Every finding is explained, with its evidence. Not scanner output. What the finding is, why it matters in this specific container, and what closes it, with the evidence cited. An explanation that cannot cite its evidence is not shown.
- Fix and accept are kept apart, and accepting is scored. What must be fixed is separated from what may be justified before anyone reads the list. A justification is drafted from the evidence, edited by the engineer, signed under their name, and scored so the reviewer knows how strong it is.
- A named person understands it and decides. The reviewer sees the whole case and approves under their own identity. The model explains. It never adds to the evidence, never proposes a basis for accepting a risk, never records a decision, and never signs. The gate policy is deterministic code with no model in the decision path.
- It stays on the record. Attributed, timestamped, anchored to an evidence hash, mapped to the controls it satisfies, and exportable the day someone asks.
None of these criteria is exotic. Each is a question an assessor, a CISO, or an authorizing official already asks about a release. Attest answers all five on every build, and keeps two states apart that most tools blur: a build that passes every scan is complete and ready for a reviewer, and nothing about it is approved until a person reads the package and signs.
Humans slow it down? Only when they have to dig.
The objection to a named person on every release is that people are slow. The objection is fair when the person is doing the work. The slow part of security review was never the decision. It was everything before it: hunting through pipeline jobs for status, logs, and artifacts; reading scanner output nobody wrote for a human; arguing about which findings matter; writing justifications from scratch; and an assessor reconstructing all of it before they could form a view. A reviewer has to understand before they sign, and understanding was the part that took months.
Attest's Explainable AI does that part. It organizes the whole pipeline by application instead of by job, and maps every gate, result, and approval to the control it satisfies, so nobody navigates by pipeline job again. It explains every finding and every gate in plain language, with the reasoning built from the scan record. It plans the fix: the approved base image to rebuild on, the package versions to move to, the Dockerfile change, in order. It drafts the justification when a finding cannot be fixed, in words an assessor can check, and scores it. And it lays the review out so the assessor sees every finding with its fix or its justification and the full evidence trail in one place.
Two words describe what the reviewer gets. Transparent, because the reviewer can see how every conclusion was reached, with lineage from commit to pipeline to merge request to decision. Traceable, because every item links back to its evidence and every decision records who made it and when. A reviewer who can see all of that understands the case in minutes and decides with confidence.
The numbers bear it out. Before Explainable AI, our own engineers took weeks to months to manage and remediate the CVEs on a build. After it, a review that took two and a half people thirty days to clear sixty containers takes one person a week to clear more than a hundred and fifty. On the pipeline underneath Attest, ARCYBER reported authorization time falling from seven months to about two hours (ArCTIC, March 24, 2026). None of that came from removing the person. It came from giving the person what they needed to decide quickly and defend the decision later. The named approver was never the bottleneck. The digging was.
What it looks like in practice
A developer pushes. The pipeline builds the container and runs the scanners against it. Attest reads the results, evaluates the gate policy, and writes the explanation for every gate and every finding. By the time the developer opens the worklist, the findings are already explained, triage is already done, and the fixes are already drafted, down to the approved base image to rebuild on and the package versions to move to. The developer fixes what must be fixed, signs the justification for what may be accepted, and rescans.
When every gate passes, the complete package goes to the reviewer's queue. The reviewer sees each finding with its fix or its justification, the evidence behind it, and the lineage from commit to build to merge request. One decision at a time, with a written basis, understood in minutes. The approval happens under the reviewer's own identity, and the record is complete the moment it happens. There is nothing to assemble later.
The CISO or the authorizing official watches the posture page move: one more application authorized, the accepted risk behind it named, the time it took on the record.
All of that is reachable from the console, and since October 2026 from the AI agents developers already use. Attest publishes an MCP server with 34 documented operations, so Claude, Claude Code, VS Code, and any other MCP client can read the findings, apply the fix plan, draft the justification, and start the rescan, under the user's own permissions and with every write logged under their name. The agent can do the work. It cannot approve. Setup guides for Claude, Claude Code, and VS Code, and what the agent can and cannot do, are in the AI clients section of the Attest documentation.
This is in production today
Ulap has been working on CYBO with the Department of War since 2023, across five SBIR awards with the Air Force, the Army, and OSW, including a Direct to Phase II; the awards are on the public record at SBIR.gov for anyone who wants to check. Attest runs on the pipeline Ulap helped develop with Army Cyber to automate the scanning, testing, and approval of containerized software for IL5 and above. CERA, the inference engine and model gateway under every CYBO product, is authorized to run at IL5.
None of that is specific to defense. The vocabulary changes, the need does not. For a commercial team, an authorization is a release gate with a signature, the posture page is the audit view, and the same record backs SOC 2, ISO 27001, and PCI DSS and answers customer security reviews. For a government program the words are already yours: gates, CCI, body of evidence, named approver. Programs that need the model and the endpoint inside their own boundary run Attest there. Everyone else runs the same product hosted, starting with early access.
Who approved this build?
The question for any organization shipping software is simple. When something in production turns out to be wrong, who said it could run, and what were they looking at when they said so? If the answer is a green pipeline, nobody decided. The scanner ran.
We built Attest so the answer is a name, the evidence behind it, and a person who understood both. Fast because it is transparent. Defensible because it is traceable. Early access to CYBO Attest is open at ulapcybo.app/early.html.
Sources: New Relic, 2026 AI Code Report (June 2026). Stack Overflow, Developer Survey 2026 (October 2026). Epoch AI, cyber vulnerability reports, monthly totals January 2022 to August 2026. Atlantic Council on ATO timelines (June 2025); Federal News Network on the DoD CIO and RMF (May 2025); Akin Gump on the Cybersecurity Risk Management Construct (October 2025); Sonatype on the RMF backlog (June 2026). IBM, Cost of a Data Breach 2025. Gartner, AI security spend (2025, 2026). Gartner via Innovation Insight on ASPM adoption (January 2025). Public reporting on the March 2026 scanner supply chain compromise and on security platform acquisitions (March 2026). ArCTIC, "platform reduces program authorization time from months to hours," DVIDS (March 24, 2026). Ulap award record, SBIR.gov. Ulap internal review figures as of October 2026.