Gixy Integration with DefectDojo

Gixy Integration with DefectDojo

Gixy is an open source static analyzer for nginx configuration files. It was originally developed at Yandex, and an actively maintained fork is published as gixy-ng (installed with pip install gixy-ng). Gixy parses a configuration, follows its includes, and runs plugins that look for security misconfigurations such as HTTP response splitting, weak origin and referrer validation, host header problems, header redefinition in nested blocks, and server version disclosure. It can write its results as JSON, which DefectDojo imports.

Gixy Integration with DefectDojo

We run Gixy against every nginx configuration in our repositories because a single misplaced directive can undo the security headers or access rules an application team thought it had. Importing the results into DefectDojo turns each issue into a Finding with the config file, the line, the offending snippet, and the plugin's own explanation of the problem. Configuration findings then sit on the same Asset as the application they front, with owners and SLAs, and reimporting after a config change shows exactly which issues the change closed.

Why Gixy Matters

nginx configuration is code that rarely gets reviewed like code. It is copied between services, edited under pressure during incidents, and full of directives whose inheritance rules surprise people.

• Gixy understands nginx semantics, including how includes and nested location blocks interact, which a text search can't do.
• Its plugins target misconfigurations with real security impact, rather than style.
• Each issue explains why it matters and what to change, so the fix doesn't depend on someone who already knows nginx well.
• It runs offline against files, so it fits in CI before a configuration ever reaches a server.

Advantages of This Integration

What changed when Gixy output started going into DefectDojo:

• Precise locations. Each Finding records the config file path and line number, so engineers can jump straight to the directive.
• Context on every Finding. The plugin's description of the issue is stored as the Mitigation and its documentation link as the References field, so the explanation travels with the Finding.
• Deduplication that tracks the directive. The Gixy Scan type deduplicates on the plugin name, file path, and line, so rescanning an unchanged config doesn't create new Findings.
• Configuration and application risk together. Gixy Findings appear next to DAST results for the same site. A missing header found by a scanner and the config line that causes it end up on the same Asset.
• Lifecycle on reimport. Reimporting after a config change mitigates the issues that were fixed, adds any new ones, and reactivates those that return.

How This Integration Works

DefectDojo imports Gixy results with the Gixy Scan scan type.

1. Run Gixy with JSON output. Point it at the main configuration file so includes are resolved:

gixy -f json nginx.conf > gixy.json

2. Import the report. In the UI, open the Engagement, choose Import Scan Results, select Gixy Scan, and upload gixy.json. For automation, use the API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=Gixy Scan" 
  -F "file=@gixy.json" 
  -F "product_name=public-web" 
  -F "engagement_name=nginx Config" 
  -F "auto_create_context=true"

DefectDojo Pro users can run the same step with Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Gixy Scan" 
  --report-path "./gixy.json" 
  --product-name "public-web" 
  --engagement-name "nginx Config" 
  --auto-create-context

3. Reimport on every config change. Send later reports to /api/v2/reimport-scan/ against the same Test so the history of each issue stays in one place.

Data Granularity: What Gets Imported

Gixy reports a config path in both file and path. The parser uses file, since path can be a virtual include location rather than where the file lives on disk.

Use Cases

In a CI/CD pipeline: Every pull request that touches nginx configuration runs Gixy and reimports the report into a Test for that repository. Reviewers see new High findings before the change merges, and fixed issues close automatically.

Hardening a fleet of reverse proxies: A platform team maintains dozens of nginx configurations for different services. Importing each into its owning Asset gives a per-team list of misconfigurations, and SLA reports show which teams are behind.

After an incident: Emergency config edits made during an outage are easy to forget. A post-incident Gixy run shows whether a temporary change left a header redefinition or a permissive origin check in place.

Validating DAST findings: When a dynamic scanner reports a missing security header or a version banner, the Gixy Finding on the same Asset points to the exact file and line responsible.

Operational Tips

• Run Gixy against the top-level nginx.conf, not individual snippets. Includes are resolved from the main file, and plugins that depend on block inheritance need the full picture.
• Because the line number is part of the deduplication hash, reformatting a config or inserting lines above a directive can create a new Finding and mitigate the old one. Expect some churn after large config refactors.
• Use one Test per repository or per server role and reimport into it, rather than importing each run as a new Test.
• Tag imports with the environment (for example tags=edge,production) when the same repository holds configs for several environments.
• Review findings with unexpected severity labels. Anything Gixy reports outside HIGH, MEDIUM, and LOW imports as Medium.
• Risk-accept intentional deviations, such as a deliberately broad origin rule for a public API, with a note and an expiration date so they come back for review.