79 checks across 23 security areas

• Web application

  16

  Most serious web bugs come down to untrusted input reaching a place where it is treated as code: a query, a template, a shell or a deserializer. OpenRouting finds those paths in your repository and tells you which ones are real.

• Wireless & radio

  14

  Radio security is mostly decided in firmware: which keys are compiled in, how Bluetooth pairing is configured, how the device joins a network. OpenRouting reads that firmware source and configuration and flags the choices that weaken it.

• Infrastructure

  7

  Servers are increasingly defined in your repository: Terraform, Ansible, Helm, Dockerfiles and committed config files. OpenRouting reviews those definitions for host-level weaknesses before they are applied.

• Memory safety

  6

  In C and C++, a single unchecked copy or overflowing size calculation can let input overwrite memory. OpenRouting surfaces those patterns in your repository and reviews whether the input is actually bounded.

• Input handling

  4

  Fuzzers find crashes by throwing input at running code. OpenRouting looks at the same weak spots from the other side: the parsers, regexes and size limits in your source that decide how much damage one malformed request can do.

• Blast radius

  3

  Every system gets compromised somewhere eventually. What decides the damage is how much the compromised piece can reach. OpenRouting reviews the permissions, credentials and data access defined in your repository to keep that small.

• Active Directory

  2

  Applications that authenticate against Active Directory or query LDAP carry directory credentials and build directory queries. OpenRouting reviews that integration code for the mistakes that expose your directory.

• APIs

  2

  APIs expose your data model directly, so the most common API bugs are about who may touch which object. OpenRouting reviews your handlers for missing ownership checks, mass assignment and unbounded operations.

• Authentication

  2

  Authentication bugs are rarely in the login form itself; they are in how tokens are verified and sessions are kept afterwards. OpenRouting reviews that code path end to end.

• CI/CD

  2

  Your pipeline holds the keys to production: deploy credentials, registry tokens, signing keys. OpenRouting reviews workflow files for the patterns that let untrusted code or text reach those secrets.

• Containers

  2

  A container is only as isolated as its configuration allows. OpenRouting reviews Dockerfiles, compose files and Kubernetes manifests for the settings that let a compromised container reach its host.

• Cryptography

  2

  Cryptography fails quietly: the code runs, the data looks scrambled, and the protection is gone. OpenRouting reviews how your code uses ciphers, hashes, randomness and TLS.

• Logging & audit

  2

  When something goes wrong, your logs are the evidence. OpenRouting reviews logging code for the gaps that make incidents hard to investigate — and the leaks that make logs a liability.

• Privilege escalation

  2

  Install scripts, packaging and service definitions decide which users can do what on a host. OpenRouting reviews them for the permissions that let a low-privileged process become root.

• Exposed information

  2

  Attackers start by collecting what you expose. A lot of that comes from the code itself: debug routes, verbose errors, files served by accident, and secrets in git history. OpenRouting finds those in your repository.

• Phishing resistance

  2

  Phishing targets people, but it leans on flaws in software: a trusted domain that redirects anywhere, an account email that changes without confirmation, a notification email users can fill with their own content. OpenRouting finds those in your code.

• Supply chain

  2

  Most of the code you ship was written by someone else. OpenRouting reviews how your repository pulls that code in — package sources, version pinning, lockfiles and build steps — so a compromised package can't slip in unnoticed.

• Triage & reporting

  2

  A scanner's raw output is a list of maybes. OpenRouting turns it into decisions: each finding is reviewed, explained and either confirmed with a fix or marked a likely false positive with the reason.

• AI / LLM

  1

  LLM features add a new kind of input — text that can steer the model — and often give the model tools. OpenRouting reviews both the application code that calls models and the agent setup committed to your repository.

• Cloud

  1

  Cloud breaches are mostly configuration, and configuration is now code. OpenRouting reviews Terraform, CloudFormation and similar files for exposure before they reach your account.

• IoT

  1

  Connected devices live in the field for years and are hard to patch, so the update path and device credentials decide how bad a single flaw gets. OpenRouting reviews firmware and device-cloud code for those weaknesses.

• Mobile

  1

  A mobile app runs on a device you don't control, so what ships in the build is effectively public. OpenRouting reviews app source, manifests and plist files for the settings that expose users and backends.

• Network

  1

  Which ports a service listens on, whether it requires authentication and whether it uses TLS are usually decided in code and config files. OpenRouting reviews those decisions in your repository.

Coverage areas reflect the check library. Code, secret and infrastructure scanning run today; other areas are rolling out.