KrakenD Integration with DefectDojo

KrakenD Audit Integration with DefectDojo

KrakenD is an API gateway written in Go, offered as an open source edition and a commercial Enterprise edition, and built on the Lura framework hosted by the Linux Foundation. Its krakend audit command reads a gateway configuration file and evaluates it against a set of security rules, returning recommendations grouped by area: authentication and authorization, HTTP transport (TLS, security headers, CORS, version banners), traffic management (rate limits, circuit breakers, timeouts, bot detection), telemetry, routing, and deprecated components. Each recommendation has a rule ID, a severity from LOW to CRITICAL, and a message. The output can be rendered as JSON for DefectDojo.

KrakenD Audit Integration with DefectDojo

Our gateway configuration decides which APIs are exposed and how they are protected, so we audit it with KrakenD's own tool on every configuration change and send the results to DefectDojo. In DefectDojo, each audit recommendation becomes a Finding on the gateway's Asset with a severity and a specific fix. The platform team owns those Findings, SLAs tell us when they are overdue, and reimports show when a configuration change resolved a recommendation or introduced a new one. Gateway hardening becomes tracked work rather than a command someone remembers to run.

Why KrakenD Audit Matters

An API gateway is the front door for every backend behind it. A missing TLS setting, a debug endpoint left enabled, or the absence of rate limiting affects every API it serves.

• The audit checks the gateway configuration itself, so it catches problems before traffic reaches the backends.
• Rules come from KrakenD, the people who know what each setting does.
• Every recommendation is a concrete action, such as enabling TLS, hiding the version banner, or adding a bot detector.
• It runs locally against a file, which makes it easy to add to a CI pipeline that deploys gateway configuration.
• A passing audit only means the evaluated rules passed. KrakenD is explicit that it doesn't prove the API is secure, which is why these findings belong next to API testing results.

Advantages of This Integration

What we gained by importing KrakenD audit results into DefectDojo:

• Configuration drift becomes visible. Reimporting each audit into the same Test closes recommendations that a configuration change resolved and flags ones a change introduced.
• Severity-based SLAs. KrakenD's CRITICAL, HIGH, MEDIUM, and LOW levels map directly to DefectDojo severities, so gateway findings follow the same deadlines as application findings.
• Fix guidance on every Finding. The recommendation message becomes the Finding's mitigation, and every Finding is marked as having a fix available.
• Exceptions with an audit trail. When a rule doesn't apply to a gateway, risk acceptance in DefectDojo records who decided and when, instead of a silent ignore flag in a CI script.
• Context with API testing. Audit findings sit on the same Asset as DAST and API scanner results for the services behind the gateway.

How This Integration Works

DefectDojo imports KrakenD audit results with the KrakenD Audit Scan scan type. The parser reads a JSON document with a recommendations array, where each entry has a rule, a severity, and a message.

1. Run the audit and render JSON. The marshal template function prints the audit result as JSON:

krakend audit -c krakend.json -f "" > krakend-audit.json

krakend audit also accepts -s to choose which severities to report and -i or -I to skip rule IDs. Use > rather than >> when writing the file: appending a second run to an existing file produces invalid JSON.

2. Import the result. In the UI, open the Engagement, choose Import Scan Results, select KrakenD Audit Scan, and upload the file. In a pipeline with the API (Community Edition and DefectDojo Pro):

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=KrakenD Audit Scan" \
  -F "file=@krakend-audit.json" \
  -F "product_name=edge-gateway" \
  -F "engagement_name=Gateway Config" \
  -F "auto_create_context=true"

DefectDojo Pro users can use Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "KrakenD Audit Scan" \
  --report-path "./krakend-audit.json" \
  --product-name "edge-gateway" \
  --engagement-name "Gateway Config" \
  --auto-create-context

3. Reimport on each configuration change. Send later audit results to /api/v2/reimport-scan/ for the same Test so resolved recommendations are mitigated and new ones are added.

Data Granularity: What Gets Imported

The audit output is compact, and the mapping is direct.

The report has no file paths, line numbers, endpoints, or CWE values, so those fields stay empty. Entries without a rule ID are skipped. Look up the rule ID in KrakenD's audit documentation for the full explanation of each rule.

Use Cases

In a GitOps pipeline: Gateway configuration lives in a repository, and every merge runs krakend audit before deployment. The result is reimported into the gateway's Test, so a pull request that disables TLS or enables a debug endpoint produces a new Finding with an owner the same day.

Across several gateways: An organization runs separate KrakenD gateways for public, partner, and internal APIs. Each gets its own Asset in DefectDojo, so hardening progress can be compared across gateways and reported by team.

For hardening projects: A platform team imports a first audit to set a baseline, assigns the High and Medium recommendations, and tracks closure against SLAs as the configuration is tightened.

Alongside API testing: Audit Findings for the gateway sit next to DAST and API scanner results for the services it fronts, so security reviews see configuration gaps and runtime findings together.

Operational Tips

• Use one Test per gateway configuration and reimport into it. Importing audits from different gateways into one Test would mitigate whatever is missing from the latest file.
• Prefer risk acceptance in DefectDojo over -i for rules you deliberately don't follow. Ignored rules disappear from the report and from your records, while an accepted risk can carry an expiration date and a reason.
• If you filter severities with -s, keep the setting stable. A narrower filter on one run looks like a batch of fixes on reimport.
• Deduplication uses the rule description, the message, and severity. If KrakenD rewords a message in a new release, the recommendation can appear as new, so expect some churn after upgrades.
• Write the audit file with > and fail the pipeline step if the audit command errors, so an empty or partial file doesn't mitigate every open Finding.
• Tag imports with the environment or configuration version (for example tags=prod,gateway-v42) to tie findings to a deployment.