CVE2CAPEC: A Daily Updated Pipeline from CVE to MITRE ATT&CK, D3FEND, and ATLAS

What CVE2CAPEC Solves and Who It Serves

CVE2CAPEC addresses a specific operational gap: turning a raw CVE identifier into a chain of related security references that an analyst or an automated system can act on. The README describes a pipeline that starts with CVEs and then derives CWE weaknesses, CAPEC attack patterns, MITRE ATT&CK techniques, and from those, D3FEND countermeasures and ATLAS techniques for AI systems. The intended user is a security operations team that wants this mapping without manually querying several MITRE databases. The project also feeds an interactive web generator hosted on the project's homepage, which suggests the authors use the same data for visualization. The tool is not an exploit scanner or a vulnerability prioritization engine; it is a data enrichment layer. For someone who needs to answer 'what attack pattern does this CVE relate to and what defensive technique counters it', CVE2CAPEC provides a scripted route.

The Chained Pipeline: From CVE to Six MITRE Taxonomies

The core mechanism is a sequence of Python scripts, each consuming the output of the previous one. The README lists the steps in order: retrieve_cve.py fetches new CVEs, cve2cwe.py maps those CVEs to CWE weaknesses, cwe2capec.py maps CWEs to CAPEC attack patterns, capec2technique.py maps CAPECs to MITRE ATT&CK techniques, technique2defend.py maps ATT&CK techniques to D3FEND countermeasures, and technique2atlas.py maps ATT&CK techniques to ATLAS techniques. This is a strictly linear data flow. Each script reads from the database folder and writes to the results folder, with the final output stored in results/new_cves.jsonl. The design assumes that every CVE has at least one CWE, every CWE leads to at least one CAPEC, and so on, which is not always true in practice. The pipeline also depends on separate update scripts for each taxonomy: update_capec_db.py, update_cwe_db.py, update_technique_db.py, update_defend_db.py, and update_atlas_db.py. These update scripts must be run before the mapping scripts, otherwise the local copies of the MITRE data will be stale.

Installation and Local Execution: The Exact Commands

The README gives a straightforward installation path. You clone the repository, change into the directory, and install dependencies with pip install -r requirements.txt. There is no mention of a virtual environment, which is a minor omission for a Python project that touches network data. After installation, you update the local databases by running five scripts in sequence: python update_capec_db.py, python update_cwe_db.py, python update_technique_db.py, python update_defend_db.py, and python update_atlas_db.py. Then you run the mapping pipeline in order: retrieve_cve.py, cve2cwe.py, cwe2capec.py, capec2technique.py, technique2defend.py, and technique2atlas.py. The README does not specify any configuration files or command-line arguments; the scripts appear to take no parameters and write to fixed locations. That is simple, but it also means you cannot easily point the tool at a custom CVE feed or change the output format without editing the source code. The project does provide a hosted version, so you can inspect the generated data without running anything locally, which lowers the barrier for evaluation.

The Daily GitHub Actions Workflow: A Free Data Service

A notable feature is that the project maintains a continuously updated dataset through GitHub Actions. The README states that the workflow runs every day at 00:05 UTC and updates the database, producing results/new_cves.jsonl. This means you can consume the output without ever running the tool yourself. For an operations team, that is a practical advantage: you get a fresh mapping file each morning, ready to be ingested into a SIEM or a threat intelligence platform. However, the README does not describe the exact structure of that JSONL file, nor does it specify how many CVEs are included per run. The workflow is a black box from the user's perspective; you trust that the actions are configured correctly and that the MITRE sources remain accessible. If a source API changes or a rate limit is hit, the daily update could silently fail, and the README offers no error-handling guidance. The project's homepage also hosts an interactive generator that uses the same data, which suggests the authors are confident in the pipeline's stability, but that confidence is not documented in the repository itself.

Real Limitations: Incomplete Mappings and Stale Data Risks

The most obvious limitation is that the mapping chain is only as good as the weakest link. Not every CVE has a CWE assignment, and not every CWE maps to a CAPEC pattern. The README does not say what happens when a step produces no results; the script might skip the entry or crash, but you cannot tell from the documentation. Another limitation is the dependency on external MITRE sources, which are updated on their own schedules. The daily workflow refreshes the local copies, but if MITRE changes a mapping retroactively, the tool will not correct historical entries unless you re-run the full pipeline from scratch, which the README does not describe. The project also has no release tags, so there is no versioned snapshot to pin for reproducibility. You either clone the latest main branch or rely on the daily generated file, and both can change without notice. For a security tool that might feed into compliance reporting, that lack of versioning is a genuine concern. Finally, the tool does not provide any confidence score or evidence for the mappings; it simply applies the relationships as defined by MITRE, which are sometimes ambiguous or context-dependent.

Alternative Approaches: Direct API Queries and Commercial Feeds

The main alternative to CVE2CAPEC is to query the MITRE APIs directly. For example, you can fetch CVE data from the NVD API, then query the CWE and CAPEC databases individually, and use the ATT&CK STIX/TAXII 2.1 feed to get technique mappings. That approach gives you full control over the mapping logic and lets you handle missing data explicitly, but it requires writing and maintaining your own integration code. Another alternative is to use a commercial threat intelligence platform like Recorded Future or Vulners, which provide pre-built CVE-to-ATT&CK mappings with confidence scores and additional context. The difference is that those services are closed-source and cost money, whereas CVE2CAPEC is free and open source. The trade-off is that the commercial feeds invest more in accuracy and enrichment, while CVE2CAPEC offers a simple, transparent pipeline that you can inspect and modify. If you need a quick, no-cost solution and you are comfortable with the GPL license, CVE2CAPEC is a reasonable starting point; if you need guaranteed coverage and vendor support, you should look elsewhere.

License and Maintenance Costs

CVE2CAPEC is released under GPL-3.0. That means any derivative work that you distribute must also be GPL-licensed. The README explicitly addresses commercial use: if you want to use the tool without being bound by the GPL, you can contact the author at contact [AT] galeax.com for additional options. That is a clear sign that the project is open source but not permissive. For an internal tool that never leaves your organization, the GPL is usually not a problem, but if you plan to embed the mapping logic into a proprietary product or offer it as a service, you need to either comply with the GPL or seek a commercial license. Maintenance cost is moderate. The project has no release history, so you cannot rely on semantic versioning. The daily GitHub Actions workflow is a maintenance burden that the author bears, but for a user who forks the repository, you would need to maintain your own workflow if the upstream stops updating. The dependency on multiple MITRE sources means that any change in their APIs will break the update scripts, and there is no indication of how actively those scripts are maintained. The README does not mention any testing or CI beyond the data update, so regressions are possible.

Editorial conclusion

Adopt CVE2CAPEC if you need a daily updated, scriptable mapping from CVE identifiers to CAPEC and MITRE technique taxonomies, and you can live with the GPL-3.0 license. Skip it if you require a maintained, versioned release, need to embed the output in a proprietary product, or want a single tool that also fetches exploit intelligence. Before relying on it, verify that the daily GitHub Actions run actually produces the results/new_cves.jsonl file you expect, and check the freshness of the underlying CVE and CAPEC data, since the tool does not guarantee completeness or accuracy of the mappings.

Official sources

1. Official documentation
2. Official README
3. Project repository