owasp/owasp-open-source-intelligence-standardAn open, vendor-neutral verification standard for traceable, reviewable, and rights-aware open-source intelligence. Current release: OOVS v0.1.0.
Every judgment traceable to its origin · every requirement testable against published criteria · AI output never mistaken for evidence
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:
What the standard asks of a working analyst.
Provenance traced to origin · corroboration established independently · judgments attributed to a named person
releases hashed so a recipient can check their copy · corrections that reach everyone who saw the original
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.
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.
The OWASP Open Source Intelligence Standard (OOSIS) is the programme. OOVS is its normative core.
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:
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.py
Validation 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.
| Question | What OOVS requires |
|---|
| 01 | Where did this come from? | Origin, time, method, and handling history travel with every item, and originals stay distinguishable from copies |
| 02 | Is it independently corroborated? | Independence counted by distinct origins, not mentions. Reposts and machine restatements of one source never become confirmation through repetition |
| 03 | Who is accountable for the judgment? | Observation, inference, assumption, and unknown stated separately. Automated output is an aid, never a witness, and a named person stays answerable |
| 04 | Does the caveat survive contact? | Confidence, limits, and handling constraints travel to the point of action, and a correction can reach everyone who received the product |
Read itThe normative text, ten requirements with objectives, evidence, procedures, and pass criteria. |
Automate itRequirements and acceptance tests published as data, with JSON Schema, so tooling can consume them. |
Record a resultA portable assessment format, with a worked synthetic example you can copy. |
| 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 |
|
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 |
| 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.
| 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.
