DefectDojo API Import Authority Turns Exposure Review into Evidence Governance

DefectDojo collects vulnerability findings from scanners and other tools. Its API can import and reimport scan results, which makes it a system of record as well as a web application. An exposed DefectDojo instance is not automatically compromised, but the permission to import evidence can change how a team interprets its vulnerability history. A reviewer who treats the visible login page as the whole exposure model will miss that governance risk.

The ZoomEye count-only snapshot on November 8, 2026 used sub_type=all, page 1, and page size 1. app="DefectDojo" returned 0. title="DefectDojo" returned 1,030. http.body="DefectDojo" returned 19,890. The zero app result is a fingerprint gap in this sample, not a statement that no DefectDojo deployments exist. The title query is the stronger candidate signal here. The body query is broad and may include documentation and reports.

DefectDojo's permission charts show separate capabilities for importing and reimporting scan results. The API v2 documentation also describes API tokens and the effect of disabling them. This separation matters because a service account created for a scanner may need import access without broad user administration. The account should be tied to a specific tool, product type, and permitted asset scope. It should not reuse a human administrator's token.

Service-user tokens need a distinct lifecycle. The documentation notes that service-user token rotation uses the service-user controls rather than the normal user token reset path. An operator should verify the actual rotation behavior after a staff change. Record the token owner, scanner, import endpoints, last successful import, and the expected failure behavior if the token is revoked. Keep the token out of scanner logs and configuration examples.

Import authority also affects evidence integrity. A public or delegated API credential that can reimport findings may alter status, duplicate records, or mark results as verified depending on the request. Review who can call the import endpoints and whether audit logs capture the change. Compare the imported scan identifier, product, engagement, and timestamp with the scanner's own records. A mismatch is a data integrity incident as well as an authentication issue.

The external review should compare title and app candidates with the asset inventory. Confirm ownership through DNS, certificates, and configuration. Check whether the instance requires authentication for the UI and API, whether anonymous access is disabled, and whether the API documentation is exposed publicly. Do not attempt to upload a test finding to a third-party instance. Use an authorized test environment for endpoint verification.

Monitoring should cover new API tokens, changes to service users, repeated import failures, and imports from unexpected networks. Alert on reimports that change many findings or affect a high-value product. Keep a read-only export of the audit history outside the application so that a compromised administrator cannot erase the only record.

The zero application count is useful because it prevents a team from equating a missing fingerprint with a missing product. The 1,030 title matches provide a candidate population. The 19,890 body matches show how far a content query can drift from product identity. The real security question is which DefectDojo deployments accept automated evidence and who controls those credentials.

Query evidence

• Collection: 2026-11-08 00:44 UTC, ZoomEye SDK, sub_type=all, page 1, page size 1.
• app="DefectDojo": 0.
• title="DefectDojo": 1,030.
• http.body="DefectDojo": 19,890.

References

• DefectDojo action permission charts
• DefectDojo service users
• DefectDojo API v2
• ZoomEye title query