August 2026 Summaries

Static application security testing (SAST) analyzes source or compiled code without running it, offering early white-box feedback in IDEs and CI pipelines but often requiring triage because findings can include false positives and may not account for runtime configuration or exploitability. Dynamic application security testing (DAST) probes a running application externally, providing black-box evidence through reproducible requests and responses while detecting runtime and configuration issues that source analysis may miss, although it runs later in development and does not identify the responsible code. The approaches are presented as complementary, with NIST recommending both static and dynamic testing across the software lifecycle. Related technologies include IAST, which combines runtime instrumentation with code-level context; SCA, which identifies vulnerable dependencies; and RASP, which blocks attacks during execution. The text emphasizes that detection tools do not themselves remediate organization-wide issues, proposing cross-repository search and automated batch changes as ways to locate repeated vulnerable patterns, apply fixes at scale, and then verify results through rescanning, retesting, and review.

DevSecOps tools embed automated security checks throughout the software delivery lifecycle, from threat modeling and secure design through code analysis, dependency and secrets scanning, dynamic testing, infrastructure and container validation, and runtime monitoring. Common categories include SAST tools such as Semgrep and SonarQube, SCA tools such as OWASP Dependency-Check and Trivy, DAST tools such as OWASP ZAP, IaC scanners such as Checkov, and runtime detection tools such as Falco, while Jira is positioned as a planning and work-tracking system rather than a scanner. The central argument is that detection alone is insufficient because teams must determine a vulnerability’s real code impact across many repositories and coordinate fixes at scale. The text presents code search and AI-assisted code understanding as ways to identify affected code, and batch-change automation as a way to create, review, and track remediation pull requests across repositories. It recommends choosing tools to cover distinct pipeline stages, prioritizing vulnerabilities using exploitability signals such as EPSS and CISA’s Known Exploited Vulnerabilities catalog alongside CVSS, and measuring DevSecOps effectiveness by fixes merged rather than alerts generated.

Dynamic Application Security Testing (DAST) evaluates deployed web applications and APIs from an external, black-box perspective by sending crafted requests and identifying runtime vulnerabilities such as cross-site scripting, SQL injection, command injection, path traversal, and insecure configurations. Its main advantage is that confirmed findings demonstrate reachable behavior in a running environment, though scanners can miss unvisited paths and generally do not identify the responsible source code. DAST complements Static Application Security Testing (SAST), which analyzes source code early and identifies specific lines but may generate false positives, and Interactive Application Security Testing (IAST), which instruments an application at runtime to connect findings with code paths but requires agent support and sufficient test coverage. Common DAST options include open-source OWASP ZAP, Burp Suite, Invicti, Acunetix, and StackHawk, with selection depending on authenticated and API coverage, CI/CD integration, false-positive management, deployment constraints, and safe scanning controls. The discussion emphasizes that compliance and security programs must remediate findings rather than merely run scans, and that teams need processes or tools for tracing runtime symptoms to source, locating recurring patterns across repositories, coordinating fixes, and retesting the original exploit path after remediation.

Deep Search uses sandboxed scripts around Sourcegraph search APIs to perform large-scale codebase audits and migrations without sending thousands of files and intermediate search results to an LLM. Rather than relying on standard agent workflows that process all raw data in a model’s context window, it runs searches, filters and cross-references findings, calculates totals, and generates structured outputs such as CSV, JSON, and SVG reports, passing only aggregated results to the model. This approach is intended to reduce token costs, limit irrelevant context, and produce more actionable results for tasks such as identifying imports of deprecated packages, locating TODO-heavy files, tracking shared-service usage, detecting outdated dependencies, and comparing implementation patterns.

A custom Claude Code fileSuggestion hook improves the @ file picker by ranking repository files using exact and fuzzy filename matches, Sourcegraph symbol-search results, and recent Git activity, addressing cases where character-based path matching returns irrelevant files or cannot find functions whose names do not appear in filenames. Exact basename matches receive the highest priority, while symbol matches enable queries such as function or type names to locate their defining files; cached symbol queries and asynchronous fetching reduce network latency. Tests on the Monty repository showed that improved filename ranking alone resolves many misleading path results, while symbol indexing is necessary for definition searches, with warm requests typically completing in about 11 milliseconds. The approach has limitations, including dependence on Sourcegraph index freshness, missing macro symbols, and ambiguity among multiple similarly named definitions. The Apache-2.0 Rust implementation is available through the Sourcegraph Community cookbook, can be configured as Claude Code’s fileSuggestion command, works anonymously for indexed public repositories, and supports private instances through endpoint and token environment variables.