Code scanning (beta)
Code scanning checks your Git repositories for security flaws in the code itself (static analysis), vulnerable dependencies, leaked secrets and infrastructure-as-code problems. Repositories are cloned and scanned on your own sensors, so your code never leaves your network: only the findings (file, line, what was found) come to OrbitalCyber. [!NOTE] Code scanning is in beta and included in every plan. It's marked Beta in the console. Automatic builds for Java and .NET (for deeper analysis), and scanning inside your CI pipeline are coming next. What a scan finds Finding What it means Code analysis (SAST) Security flaws in your own code, such as SQL or command injection, cross-site scripting, unsafe deserialization, path traversal, weak cryptography and disabled TLS checks. See Code analysis below. Code quality Likely bugs and maintainability problems: undefined names, unreachable code, empty catch blocks, values compared with themselves, ignored results. Also how much of the code is duplicated. See Code quality. Vulnerable dependencies Libraries your code uses (from package-lock.json, pom.xml, *.csproj, go.sum, requirements.txt, composer.lock, Gemfile.lock, Cargo.lock and more) with known vulnerabilities, with the version that fixes them. See Java and .NET dependencies below. Secrets Keys, tokens and passwords committed to the code. OrbitalCyber records the file, line and kind of secret. The secret itself is never stored or shown. Infrastructure as code Problems in Terraform, Kubernetes manifests, Helm charts, Dockerfiles and CloudFormation templates, for example a storage bucket open to the public. Repositories and components Each repository becomes a Code repository asset. Repositories often hold several projects in different languages, so each scan splits the repository into components: one per build or package file. For example: a Maven or Gradle module; a .NET project; an npm package; a Python or Go project; a Terraform folder. Each component is a child asset of the repository, and every finding goes on the component whose folder holds the file. The repository's page shows: its language breakdown and last scan (branch and commit); every open finding across its components; the components themselves. A later scan marks a finding fixed when it's gone from the code. A repository that couldn't be scanned changes nothing. Code analysis Each scan analyses the code with the analyzer for each language the repository has. No build is needed. Language Analyzer JavaScript, TypeScript ESLint with eslint-plugin-security and eslint-plugin-no-unsanitized Python Bandit Go gosec (data-flow checks included) PHP Psalm taint analysis (follows user input to dangerous calls) Java, Kotlin, Scala, C#, Ruby, Rust, C, C++, Swift Opengrep with OrbitalCyber's own rules One finding per rule and component. It lists where the rule matched (up to 20 places: file and line) and how to fix it. OrbitalCyber stores the file, line and the analyzer's message, never your source code. Not analysed: test code (test folders and files such as *_test.go or *.spec.ts), and third-party libraries copied into the repository, such as minified files, well-known libraries like jQuery and third_party folders. Which analyzers ran: the scan's page shows them for each repository, under Scans → the scan → Repositories. The repository's page shows them too (Assets → the repository). If an analyzer can't analyse a repository, the others still run, and the scan says why. Go: gosec reads type information, so the sensor downloads the repository's Go modules (from the Go module proxy) while it scans. Private modules it can't download make the analysis less precise but don't stop it. None of the analyzers runs your code. They use OrbitalCyber's own settings, not your repository's ESLint or Psalm configuration, plugins or autoloaders. Static analysis finds likely problems, and some will be false positives. Each finding shows the places and the analyzer's explanation, so you can check…
OrbitalCyber documentation