The Open-Source Label Needs an Evidence Packet

On July 30, the Cybersecurity and Infrastructure Security Agency published new guidance for federal agencies using open-source software. Its treatment of AI draws a boundary that many buyers have avoided: access to a model or its weights may still leave the system too opaque for the security review an institution needs.

CISA says agencies should approach open-source AI differently from conventional open-source software. Before treating an AI system as open source for risk-management purposes, an agency should have enough transparency into the relevant components, including training data. The guide says a model without accessible training data and a training pipeline should be handled as proprietary software with incomplete provenance.

That is federal guidance, not a universal legal definition. It does not establish that open models are less safe than closed ones. CISA has also recognized that open foundation models can support competition, innovation, and cybersecurity. The practical point is narrower: the license and the security evidence answer different questions.

The Open Source Initiative’s Open Source AI Definition 1.0 protects the freedoms to use, study, modify, and share an AI system. It requires detailed information about training data, complete training and running code, and model parameters in the preferred form for modification. It does not require the full raw training dataset to be publicly available.

CISA sets a higher access threshold for the federal security decision it is describing. Its guide points to risks involving corrupted model files, manipulated weights, modified data or labels, and poisoned models. When the underlying evidence is unavailable, a reviewer may struggle to locate the source of a problem or determine how it entered the system. Full access still cannot prove that a model is safe. It gives the reviewer more material to inspect when something fails.

The two institutions are answering overlapping questions from different positions. OSI defines the freedoms and materials associated with open-source AI. CISA tells an agency what evidence it should expect before accepting security risk. A model can satisfy one threshold while leaving the other review incomplete.

This is a useful distinction for any operator buying, integrating, or approving AI. “Open” should be decomposed into separate fields:

What legal freedoms does the license provide?
Which artifacts are actually accessible?
Can the training process or important parts of it be reproduced?
What security evidence exists, and who checked it?
Which facts are unknown or withheld?
Who accepted the remaining risk for this specific use?

CISA’s July 29 update to the minimum elements for a Software Bill of Materials points in the same direction. The baseline now covers open-source software, AI software, and software as a service. New elements include an author signature, generation context, tool and version details, component hashes, and license information. The guidance also distinguishes information the author does not know from information that is known and deliberately withheld.

That last field may be as useful as another disclosure. It tells a buyer where confidence ends.

Verification bottleneck

Verification is becoming the scarce institutional function.

What moved faster: Open-weight releases, fine-tuned variants, and downloadable AI components can circulate faster than procurement and security teams can inspect them.
Who now has to verify: Model developers, package hosts, buyers, security reviewers, legal and procurement teams, and named decision owners each hold part of the evidence chain.
Where the bottleneck sits: Teams need to connect licenses, model artifacts, data provenance, tests, unknowns, compensating controls, and final acceptance into one reviewable record.
What to watch next: Federal contracting language, AI-specific SBOM adoption, vendor disclosure formats, and independent review services that show their method rather than issuing a vague trust badge.

Opportunities

Where value may appear for builders and operators:

An AI artifact manifest that records weights, code, data information, evaluations, versions, hashes, licenses, omissions, and known unknowns.
A procurement evidence-packet generator that attaches source artifacts to reviewer notes, exceptions, controls, and named sign-off.
A model provenance comparison service that lets smaller teams compare disclosure depth without rebuilding the same source trail.
A lightweight unknowns register with an owner, review date, compensating control, and escalation trigger for every unresolved field.
A bounded paid review product for teams that need a documented assessment but cannot staff a full AI security office.

These are practical orientation ideas, not cybersecurity, legal, procurement, business, financial, or investment advice. A useful product would show its evidence and limits. It would leave the acceptance decision with a qualified human.

The operator test is simple: does the available evidence fit the proposed use, and can someone explain the decision later?

The Open-Source Label Needs an Evidence Packet

Verification bottleneck

Opportunities

Sources