Integrated Security Measures#
Gold Digger employs a multi-layered security approach, integrating several tools and policies throughout its development and release lifecycle. The following outlines the confirmed security measures and enforcement mechanisms.
Supply Chain Security: cargo-audit, cargo-deny, and OpenSSF Scorecard#
Supply chain security is enforced using cargo-audit and cargo-deny. These tools are integrated into CI/CD workflows to automatically audit dependencies for known vulnerabilities and enforce license and security policies. The just audit and just deny commands run these checks locally, while CI jobs execute them on every workflow completion, daily schedule, and manual trigger. Any critical vulnerability or non-compliant license detected by these tools will block the release pipeline.
The project runs OpenSSF Scorecard checks via the scorecard.yml workflow to evaluate supply-chain security best practices. Scorecard analyzes the repository against security heuristics covering branch protection, dependency management, code review practices, and vulnerability disclosure. Results are published to GitHub's code-scanning dashboard and the OpenSSF Scorecard API, and the project displays an OpenSSF Scorecard badge on the README. This automated assessment complements cargo-audit, cargo-deny, Grype, and Cosign to maintain security posture compliance across the development lifecycle.
SBOM Generation: CycloneDX Format#
Software Bill of Materials (SBOM) generation is automated for every release using the cargo-cyclonedx tool via the command cargo cyclonedx --format json. cargo-cyclonedx is the canonical SBOM generation tool for this project because it reads only the project's Cargo.lock file. Syft scans the filesystem and can pick up stale Cargo.lock files in directories like megalinter-reports/, producing false positives in the SBOM. This distinction is a security best practice to ensure SBOM accuracy and avoid supply chain confusion from stale dependencies being included.
SBOMs are produced in CycloneDX format and included as release artifacts. Developers can inspect SBOMs locally with the just sbom command (which uses cargo-cyclonedx) or analyze generated SBOMs using tools like syft or Grype. SBOMs provide a complete inventory of dependencies for compliance and vulnerability assessment.
Vulnerability Scanning: Grype#
Grype is used for vulnerability scanning of release binaries and SBOMs. The just security command combines cargo-audit, cargo-deny, and Grype scans for comprehensive coverage. In CI/CD, Grype scans SBOMs and binaries for known vulnerabilities, and any critical findings will block the release. Developers can run Grype locally to generate vulnerability reports from SBOM files.
Example:
grype sbom:gold_digger-x86_64-unknown-linux-gnu.tar.gz.sbom.cdx.json
Artifact Signing: Cosign and GitHub OIDC#
All release artifacts are signed using Cosign with keyless authentication via GitHub OIDC. Each binary is accompanied by a .sig signature and .crt certificate file. Verification requires checking the signature and certificate identity against strict regex patterns to prevent forgery. The trust model is rooted in GitHub's OIDC identity and Sigstore's transparency log.
Example verification:
cosign verify-blob \
--certificate gold_digger-x86_64-unknown-linux-gnu.tar.gz.crt \
--signature gold_digger-x86_64-unknown-linux-gnu.tar.gz.sig \
--certificate-identity-regexp "^https://github\.com/EvilBit-Labs/gold_digger/\.github/workflows/release\.yml@refs/tags/v[0-9]+\.[0-9]+\.[0-9]+$" \
--certificate-oidc-issuer-regexp "^https://token\.actions\.githubusercontent\.com$" \
gold_digger-x86_64-unknown-linux-gnu.tar.gz
Logging Policies#
Gold Digger logs all database access attempts and monitors for unusual query patterns. Security events trigger alerting mechanisms. Sensitive information, such as credentials, is automatically redacted from logs and error outputs. Database URLs are sanitized, and passwords are replaced with ***REDACTED*** in all outputs. The project strictly prohibits logging or exposing database credentials in any output or error message.
TLS Configuration#
Gold Digger enforces TLS/SSL for all database connections using rustls, supporting only TLS 1.2 and 1.3. The CLI provides mutually exclusive flags for four TLS modes: platform trust (default, full validation), custom CA trust, skip hostname verification (development only), and accept invalid certificates (testing only, dangerous). Security warnings are displayed for insecure modes, and errors are mapped to specific exit codes for automated handling. All credentials in connection strings are redacted in logs and error messages.
Example CLI usage:
gold_digger --db-url "mysql://user:pass@prod.db:3306/mydb" --query "SELECT * FROM users" --output users.json
# Default: platform trust, full validation
gold_digger --db-url "mysql://user:pass@internal.db:3306/mydb" --tls-ca-file /etc/ssl/certs/internal-ca.pem --query "SELECT * FROM sensitive_data" --output data.json
# Custom CA trust
Release Blocking on Critical Vulnerabilities#
Release pipelines are configured to block deployment if any critical vulnerabilities are detected by cargo-audit, cargo-deny, or Grype. CI/CD workflows fail on detection of non-compliant licenses, outdated dependencies, or critical security issues, preventing the creation or publication of releases until all issues are resolved.
Note: While secret scanning with Checkov was requested, there is no evidence of Checkov integration in the current documentation, codebase, or workflow configuration. All other measures are confirmed and enforced as described.
