Every static analysis tool on the market has the same dirty secret: the majority of its output is noise. Linters, SAST tools, dependency scanners — they all generate issues that are technically correct and practically irrelevant. Teams learn to ignore the output, which defeats the whole point of having a scanner. The DNA bi-strand audit, one of the modules inside the Hyperbolic Security Suite, is a structural fix for that problem, and it is borrowed almost directly from biology.
DNA stores information on two complementary strands running in opposite directions. A base on one strand is only meaningful if it pairs cleanly with a base on the other. Mismatches stand out precisely because they are obvious at the pairing sites, not because either strand alone is particularly careful. The audit uses the same trick: two analysis passes run over the codebase in opposite directions, and a finding is only kept if both passes independently report it at the same pairing point.
Strand A starts at the top of the project and walks downward through decreasing levels of abstraction.
This strand is excellent at catching drift, unimplemented specs, and missing test coverage. It is bad at catching low-level bugs because by the time it reaches the bottom, it has already filtered through many layers of abstraction.
Strand B starts at the lowest level of the project and walks upward.
This strand is excellent at catching low-level bugs, vulnerable dependencies, and concrete misuses. It is bad at catching design-level mistakes because it has no architectural model to compare against.
Strand A and Strand B each have a predictable failure mode: one misses the forest, one misses the trees. Running them independently in opposite directions means the blind spots do not overlap. Every base pair they form is a finding that survived two very different review styles.
After both strands finish, the auditor looks for base pairs: locations where Strand A flagged something and Strand B also flagged the same location (or its pair point in the opposite direction). A Strand A finding like "the architecture document claims all RPC is authenticated, but the payment-service module does not enforce auth on its ingress handlers" only gets kept if Strand B independently reports "the payment-service integration handler accepts unauthenticated POSTs." Either finding alone might be a doc error or a false positive. Together, they are a real vulnerability.
Findings that only appear on one strand are not silently discarded — they go into a secondary "single-strand" pile for human review. In practice the single-strand pile is 90% noise, which is exactly the kind of noise traditional tools drown you in. The base-pair pile is almost always actionable.
False positives in static analysis come from each tool's narrow assumptions. A SAST tool flags SQL concatenation because it could be injection-prone, without knowing the input is an integer three layers up. A dep scanner flags a CVE because your lockfile pins a vulnerable version, without knowing the vulnerable path is never imported. Strand B, on its own, produces all of these. But Strand A — which has read the architecture and knows the integer contract — does not. So the false positive never forms a base pair, and it is filtered automatically. No hand-tuning required.
The auditor is two independent analyzers that meet at a join step. Strand A is driven by an LLM walking the docs and code hierarchically with a summary cache. Strand B is a rule engine plus a dependency graph walker. Both strands emit findings into a common hyperbolic embedding, and the join step looks for collisions inside the trust tube. The full source lives in the SCBE-AETHERMOORE monorepo under cyber-suite/dna-audit/, and it ties into the broader SCBE GitHub ecosystem as the auditor-of-record for every other repo under the org.