What AppSec tools do you actually rely on in production?

In the realm of database-centric application architecture, the boundary between application logic and data layer security is increasingly porous. While my primary focus is on data integrity and performance, I've found that robust AppSec practices are non-negotiable for maintaining trust in the data tier itself. The market is saturated with vendors and open-source projects, but after evaluating several in production contexts, I've distilled my reliance to a core set that complements a data-heavy stack.

My production stack prioritizes tools that integrate seamlessly into CI/CD pipelines and provide actionable, low-noise results. I avoid tools that require extensive manual intervention or produce overwhelming volumes of false positives, as they quickly become shelfware.

* **Static Application Security Testing (SAST):** For code analysis, I rely on **Semgrep**. Its pattern-matching approach, while sometimes less sophisticated than some heavy-duty analyzers, offers tremendous flexibility. Crucially, it allows me to write custom rules targeting insecure database access patterns—think SQL string concatenation bypassing ORM safeguards, or improper handling of connection strings. The ability to codify security rules specific to our data access layer is invaluable.
```yaml
# Example Semgrep rule to flag raw SQL with potential concatenation
rules:
- id: raw-sql-concatenation-python
patterns:
- pattern: f"SELECT ... FROM ... WHERE user_id = {$_VAR}"
- pattern: "SELECT ... FROM ... WHERE user_id = " + ...
message: "Potential SQL injection via string formatting/concat."
severity: ERROR
languages: [python]
```

* **Software Composition Analysis (SCA):** **Dependabot** and **Trivy** are used in tandem. Dependabot integrates natively with GitHub for automated dependency updates and PR creation, which is excellent for maintenance. Trivy is used in the pipeline for broader vulnerability scanning of container images, ensuring that the database client libraries and underlying system packages (e.g., OpenSSL) are accounted for.

* **Secret Scanning:** **Gitleaks** is run as a pre-commit hook and in the pipeline. It's lightweight and highly effective at preventing hardcoded secrets—a database connection string, a Redis AUTH token, or a GCP service account key—from ever reaching the repository. This is a first-line, critical defense.

* **Dynamic Analysis & Runtime:** For web applications, **OWASP ZAP** is integrated into the deployment pipeline for a baseline scan of any exposed API endpoints. Furthermore, I leverage **PostgreSQL's** and **MySQL's** native audit logging capabilities to create a secondary runtime defense layer. Unexplained query patterns can be a symptom of a breached application layer.
```sql
-- Example: Enabling detailed audit logging in PostgreSQL
ALTER SYSTEM SET log_statement = 'all';
ALTER SYSTEM SET log_connections = on;
ALTER SYSTEM SET log_disconnections = on;
-- (Note: This is for illustration; a production config would be more granular and performance-conscious)
```

I am notably skeptical of monolithic, all-in-one AppSec platforms that promise the moon. In my experience, they often fail to provide the depth needed for database interaction scrutiny. The curated, best-of-breed approach outlined above, while requiring some integration effort, yields far higher signal-to-noise ratio and aligns with the principle of defense in depth. I am particularly interested in how others instrument their database layers to detect application-level breaches, or if there are tools that effectively correlate SAST findings with observed query patterns in managed services like RDS or Cloud SQL.