Security model¶
The project audits security-adjacent configuration, so its own data-handling boundary is deliberately strict.
Tokens¶
Authentication tokens are sent through the PRIVATE-TOKEN request header. They are not added to
URLs.
Transport errors are translated to safe exceptions without echoing the underlying request object, because request objects can contain headers.
CI/CD variable values¶
The GitLab variables API can return values. The collector immediately reduces each record to:
- key
- protected
- masked
- hidden
- environment scope
- variable type
The value field is deliberately discarded before audit snapshots and findings are created.
Regression tests use synthetic secret-like values and verify that they do not survive into model or result representations.
Permission limitations¶
A 403 or unavailable tier-specific endpoint is not interpreted as a weak configuration.
Checks become unavailable/not applicable where the state cannot be established.
Static CI analysis¶
The YAML parser uses a safe loader and tolerates GitLab custom tags such as !reference.
Static analysis reports only signals it can establish. Dynamic includes are not guessed.
Logs and fixtures¶
Contributors should never add:
- real GitLab tokens
- real CI/CD variable values
- unsanitised API payloads containing secrets
- credential-bearing request dumps
Use synthetic fixtures for secret-handling tests.
Vulnerability reporting¶
See the repository SECURITY.md for reporting guidance. Do not publish credentials or sensitive
reproduction data in a public issue.