MAGDOX Code Security
Source-code security review, in your environment.
MAGDOX Code Security brings source analysis, dependency review, secrets detection and software inventories into one scan that runs on your machines and reports to one dashboard.
Contact us or book a call
Access is arranged with our team. Contact us or book a call.
Product direction
Scan locally. Report centrally.
The magdox CLI runs on a developer machine or CI runner, pulls signed rule bundles, scans the repository in place and sends only the findings to your organisation’s dashboard. Source code never leaves your environment. The dashboard is where security teams see every repository, triage findings, record decisions and pull reports.
Access is arranged with our team. We scope project types, pipeline and reporting needs with you, then set up an evaluation. Use the contact form or book a call.
Review workflow
Scanned locally
Source, dependencies and configuration, on your machines
Findings sent
Rule, path, line, fingerprint and severity. No source.
Reviewed centrally
Dashboard, decisions, reports and exports
An illustration of the review stages, not a product screenshot.
Capability areas
Broad scope. Explicit limits.
Open an area to see what it covers and the limits a reviewer needs to understand. Coverage for your languages and project types is confirmed during scoping.
Source-code securitySAST
Scope
Static review of first-party code, including relevant dataflow and security patterns where supported.
Meaningful limit
Coverage will depend on the language, framework and analysis engine.
Dependency securitySCA
Scope
Direct and transitive dependencies, known-vulnerability matches, dependency paths, licence information and available remediation context.
Meaningful limit
A dependency match does not establish that a vulnerable path can be reached.
Software inventoriesSBOM
Scope
Identified components, versions, relationships and available licence data, with an explicit inventory scope.
Meaningful limit
A source inventory, resolved dependency inventory and built-artifact inventory describe different things.
Cryptographic inventoriesCBOM
Scope
Supported algorithms, cryptographic libraries and usage relationships found in available code and configuration.
Meaningful limit
Uncertain or unrecognised usage must remain visible. This is not a promise of complete key discovery or post-quantum safety.
Secrets reviewCode & configuration
Scope
Possible credentials and sensitive values in supported source and configuration, with values redacted in previews and reports.
Meaningful limit
Detection does not establish that a credential is active. No credential validation or exploit execution is promised.
Security configurationRepository context
Scope
Relevant repository, build, dependency and infrastructure-as-code configuration where supported.
Meaningful limit
Repository configuration does not provide visibility into the infrastructure actually deployed.
Contextual code reviewAcross supported files
Scope
Potential security problems across supported files and components, with the surrounding evidence available to reviewers.
Meaningful limit
Business-logic findings require application context and human judgment.
Findings workflowTriage & history
Scope
Severity, confidence, affected locations, explanatory evidence, deduplication, baselines, reviewer dispositions and rescan history.
Meaningful limit
Reviewers determine applicability and remediation; automatic production fixes are outside the proposed scope.
Reports & exportsReview records
Scope
Human-readable reports and machine-readable exports for supported findings and inventories, generated locally by the CLI or downloaded from the dashboard.
Meaningful limit
SARIF, software BOM formats and cryptographic inventory representations serve different purposes; see the format guide below.
Proposed review workflow
From a project to a review record.
Contact us or book a call
STEP 1
Select a project
Run the CLI from a repository or supported project directory.
STEP 2
Set the review scope
Select the relevant checks and available project context.
STEP 3
Scan locally
The CLI pulls signed rules and scans in place. Source code stays on the machine.
STEP 4
Review the evidence
Findings reach the dashboard; triage them with evidence, uncertainty and coverage.
STEP 5
Export review records
Produce supported reports and software inventories.
STEP 6
Compare a later review
Use a baseline to review changes and earlier decisions.
Reports & inventories
The format follows the evidence.
A finding report and a component inventory answer different questions. The formats are not interchangeable, and only supported information can be represented.
| Record | Format | Scope |
|---|---|---|
| Human review | Local, human-readable reports | Findings, explanatory evidence, reviewer context and analysis coverage. |
| Supported findings | SARIF | Analysis results and affected locations supported by the relevant tool. |
| Software inventory | CycloneDX / SPDX | Components, relationships and available licence information; identify source, resolved-dependency or artifact scope. |
| Cryptographic inventory | Compatible CycloneDX representation | Supported cryptographic assets and usage relationships, with uncertainty recorded. |
Deployment & data boundaries
Your source stays yours. Only findings travel.
Scanning happens where the code lives. The CLI downloads signed rule bundles and vulnerability data, analyses the repository in place, and uploads a findings payload: rule identifier, file path, line range, a fingerprint hash, severity, confidence and the component list for the software inventory. Source files are never uploaded.
Code snippets are off by default. An organisation can choose redacted or full snippets if its reviewers want them in the dashboard. --show-payload prints exactly what a run will send, and --local-only produces a full local report while sending nothing. For environments that cannot reach the internet, a self-hosted dashboard and offline rule bundles are available by arrangement.
Decided
- Scanning runs locally; source code is never uploaded.
- Snippets are off by default; payloads can be inspected before sending.
- Reports download from the dashboard or straight from the CLI.
- Reviewer decisions are recorded with their reasons and carried across rescans.
Outside the proposed scope
Penetration testing, DAST against live services, fuzzing, exploit execution, test generation, runtime protection and automatic production remediation are not part of this product.
Static application security testing is the conventional name for SAST. It does not mean generating or running your application’s tests.
Questions, answered plainly
Before you plan an evaluation.
What does it review?
The scope covers supported first-party source code, dependencies, cryptographic usage, possible secrets and security-relevant configuration. Findings remain subject to coverage limits and reviewer assessment.
How do we get access?
Access is arranged with our team rather than through a public download. Use the contact form or book a call; we scope your project types, pipeline and reporting needs, then set up an evaluation.
Is it a CLI or a SaaS product?
Both, with a clear split. The CLI scans on developer machines and CI runners, so source never leaves your environment. The dashboard is hosted by MAGDOX and receives only findings metadata, giving security teams one view across every repository. A self-hosted dashboard is available by arrangement.
How is it different from FDIE?
FDIE examines supported firmware images and keeps evidence across releases; it has its own team, hosting and documentation at fdie.dev. MAGDOX Code Security focuses on source code and dependencies. They are distinct products; no shared pipeline or automatic source-to-binary connection is promised.
Does my source code leave our network?
No. Analysis runs locally and source files are never uploaded. The CLI sends findings metadata only: rule, path, line range, fingerprint hash, severity and SBOM components. Snippets are off by default and can be enabled per organisation. --show-payload shows exactly what will be sent; --local-only sends nothing.
Which languages and platforms are supported?
Language, framework, operating-system and project coverage is confirmed with your team during scoping and stated in the engagement. No blanket coverage or benchmark claim is made here.
Will it generate SBOMs and CBOMs?
Yes. Software inventories export as CycloneDX or SPDX and cryptographic inventories as CycloneDX CBOM. Each inventory states its scope, relationships and any uncertainty.
Does a clean review establish security or compliance?
No. An absence of findings is limited to the checks, evidence and coverage of that review. It does not establish that a product is secure, that all vulnerabilities were found, or that a compliance obligation has been met.
Next step
Tell us what a useful review looks like.
Share your project types, environment and reporting needs. No source code is needed for this conversation. Confirmed coverage and evaluation availability will be published on this website.
Discuss an evaluation