Security architecture
The security posture of a Vetrix deployment: how credentials are kept out of git and rotated when they slip through, how the scanning backends are enabled and what they report, and the boundary-by-boundary threat model of the CI/CD execution chain.
Secrets and credentials
- Secret Detection — The pre-receive secret scan. Covers how the
server inspects every new commit's diff against a library of roughly 150 regex
patterns before refs are updated, the rejection output an author sees in
blocking mode, the
block/warn/offinstance modes and the admin settings call that sets each one, the categories of credential recognised (cloud keys, source-control and CI tokens, database connection strings, private keys, SaaS API keys and high-entropy generic patterns), the remediation order for a secret that is already in history, the repository-scoped.vetrix-secret-ignoreallowlist and the role required to edit it, and the audit-log events written for blocks, overrides and allowlist changes. - Credential Rotation Runbook — What to do after a push is
rejected for a detected secret. Step one is rotation at the issuing system,
with concrete key-rolling and audit-log steps for AWS, Google Cloud, Azure,
GitHub, GitLab, Stripe, Twilio, unidentified bearer tokens and private-key PEM
blocks. Step two removes the offending commit locally — soft reset, interactive
rebase, or a
git filter-repohistory scrub. Step three re-pushes with--force-with-leaseagainst a second scan. Step four sets the escalation criteria for paging the security team and documents the audited break-glass push option, the permission and instance toggle that gate it, and the baseline file that silences a confirmed false positive.
Scanning and threat model
- Security Scanning — The scanner surface end to end: the four
scan types (static analysis with its CWE classification and severity ladder,
dependency scanning of lock files against the open vulnerability database,
secret detection, and container image scanning), where findings surface across
merge requests, the Security tab and the job log, the dismissal reasons and
their audit trail, the merge-blocking thresholds and the recorded override, the
findings REST API, enabling each backend from the admin settings panel with the
environment variables acting only as a first-boot seed, the boot-time binary
probe and its
scanner.tool.detected/scanner.tool.missinglog lines, the dependency-scanning enablement runbook, the capability-discovery response shape consumed by the trigger-scan dropdown, and five common failure modes with the checks that resolve them. - CICDv2 threat model — The five-layer pipeline execution chain — API server, leader-elected runner controller, per-host agent, outer Docker-in-Docker container and inner per-job container — treated as five security boundaries. Each layer records the code and configuration that enforces it, the residual risk if that enforcement fails, a mitigation status of Mitigated, Partial, Accepted risk or Pending, and the behaviours pinned by tests. Includes the explicit out-of-scope list, and covers attach-token issuance and one-shot redemption, the leader write-gate, mutual TLS trust anchoring, the outer-image allowlist, capability drops with seccomp and AppArmor profiles, per-tenant network isolation, and the scope and lifetime of the per-job token.