Open-source intelligence now informs decisions that affect liberty, safety, and national security.
OOVS is an open standard that makes those decisions defensible.
Read the standard · The ten requirements · For evaluators · OWASP project page
An intelligence product is only as good as the account you can give of it. Most open-source work cannot answer four questions under scrutiny:
| Question | What OOVS requires | |
|---|---|---|
| 01 | Where did this come from? | Provenance recorded as part of the record, not as metadata beside it |
| 02 | Who decided it was credible? | A named, accountable judgment with stated confidence |
| 03 | Would another analyst agree? | A method reproducible from the published trace |
| 04 | Has the record changed since? | Per-release SHA-256 fingerprints, so alteration is detectable |
What the standard asks of a working analyst.
Provenance traced to origin · corroboration established independently · judgments attributed to a named person
integrity fingerprinted so alteration shows · corrections that reach everyone who saw the original
|
The normative text, ten requirements with objectives, evidence, procedures, and pass criteria. |
Requirements and acceptance tests published as data, with JSON Schema, so tooling can consume them. |
A portable assessment format, with a worked synthetic example you can copy. |
Also worth reading: the release notes, the safety, rights, and misuse policy, governance, and how OOVS sits against prior art.
Each requirement states an obligation, the evidence that demonstrates it, how an assessor tests it, and what counts as failure. None depends on a particular tool, vendor, or platform.
| ID | Requirement |
|---|---|
OOVS-v0.1.0-01 |
Authorised purpose and proportionality |
OOVS-v0.1.0-02 |
Collection boundary and data minimisation |
OOVS-v0.1.0-03 |
Source provenance and integrity |
OOVS-v0.1.0-04 |
Source and claim assessment |
OOVS-v0.1.0-05 |
Corroboration and confidence |
OOVS-v0.1.0-06 |
Analytic transparency and reproducibility |
OOVS-v0.1.0-07 |
Rights, privacy, and safeguarding |
OOVS-v0.1.0-08 |
AI and automation assurance |
OOVS-v0.1.0-09 |
Dissemination and action controls |
OOVS-v0.1.0-10 |
Governance, audit, and improvement |
Cite a requirement by its identifier, for example OWASP OOVS v0.1.0, OOVS-v0.1.0-04. The
plain-language walkthrough
explains each one without the normative wording.
|
Every record carries its own proof. A source, a claim, an assertion, and the evidence behind it travel together, with confidence and uncertainty stated rather than implied. |
Every hop is recorded. Collected, normalised, verified, cited — each step carries a hash, so a claim stays auditable back to its origin. |
|
One standard, many systems. OOVS describes a layer between the tools that gather and the systems that decide, rather than another platform to adopt. |
Built for work that gets questioned. Government, defence, intelligence, public safety, and critical infrastructure, where a decision has to survive review. |
| Capability | How it is delivered |
|---|---|
| A testable assurance baseline | Ten L1 requirements with objectives, evidence, procedures, and pass criteria |
| Two clear assessment targets | A defined workflow or a defined intelligence product |
| Portable results | JSON Schema for assessment output, plus a worked synthetic example |
| Automatable adoption | Requirements, tests, and schemas published as data, not only prose |
| Verification discipline | Source-origin checks so repeated reporting is not mistaken for independent corroboration |
| Rights-aware controls | Purpose, minimisation, provenance, safeguarding, AI accountability, dissemination, and correction |
| Interoperability grounding | Conservative mappings to established public guidance |
The wider programme, and what is available now
The OWASP Open Source Intelligence Standard (OOSIS) is the programme. OOVS is its normative core.
| Asset | Available now | Purpose |
|---|---|---|
| OOVS | v0.1.0 released | Normative verification requirements, tests, and assessment format |
| OIG | 0.1 preview schema and synthetic graph | Minimal graph model for provenance-preserving exchange |
| OTTM | 0.1 preview schema and first technique record | Structured technique and tool-capability vocabulary |
| OOTG | Scenario template | Practitioner testing scenarios with safe fixtures |
| Top 10, packs, benchmarks, landscape, translations, reference flow | Published method and design notes | Roadmap items built on OOVS implementation evidence |
The roadmap sequences the next release: a reproducible synthetic cyber-exposure/CTI vertical slice built on OOVS.
Scope, and what this standard deliberately is not
OOVS assesses a defined workflow or product against published requirements. Within that scope it is designed to be used immediately by security teams, investigators, journalists, NGOs, researchers, and public-interest organisations.
Like other voluntary standards, OOVS is not a certification or accreditation scheme, does not determine legal compliance or evidentiary admissibility, and does not imply endorsement by any government, agency, court, or vendor.
It complements rather than replaces existing guidance:
| Prior art | Relationship |
|---|---|
| Berkeley Protocol | International professional and ethical standards for digital open-source investigation |
| ICD 203 / ICD 206 | Analytic standards and sourcing requirements |
| W3C PROV | Provenance data model |
| STIX/TAXII | Threat intelligence representation and exchange |
| CASE/UCO | Cyber-investigation ontology |
OOVS is a standard, not an intelligence platform such as OpenCTI, MISP, or Aleph.
Every claim this repository makes about itself is checkable with one command.
python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install -r requirements-validation.txt
python3 scripts/validate_assets.pyValidation covers JSON Schema conformance, cross-file semantics, Markdown/JSON requirement parity, positive and expected-failure fixtures, local documentation links, and release-manifest file hashes. The same command runs in CI on every push.
|
Manish Tripathy — Project leader |
|
The authoritative leader record is the OWASP project page. Open review roles are listed in MAINTAINERS.md, and the project actively wants reviewers from different organisations, regions, and legal contexts.
Read CONTRIBUTING.md, GOVERNANCE.md, and the Code of Conduct. Implementation results, assessor feedback, technique records, mappings, translations, and reviews are all welcome.
Use synthetic, consented, anonymised, or non-sensitive public examples. Do not submit personal data, live-case material, victim information, target lists, credentials, or harmful operational detail.
Copyright © 2026 OWASP Foundation and contributors.
Unless a file states otherwise, documentation and structured standard content in this repository are licensed under the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0). You may share and adapt the material, including commercially, provided you give appropriate credit, link to the license, indicate changes, and license your contributions under the same terms.
Sixty seconds on why verification is the constraint, the data model that carries proof with every record, and the provenance chain that keeps a claim auditable back to its source.
OWASP and the OWASP logo are registered trademarks of the OWASP Foundation, Inc.
Incubator stage means the Foundation hosts this project; it is not a review or an endorsement of the content.