Source-code analysis
Find the risky code. Understand the path to it.
A useful finding gives an engineer enough context to investigate. Code Security examines supported source and configuration on the developer machine or CI runner, connects a result to its location, and keeps the explanation beside the remediation guidance. Your team can review locally or send selected scan results into the console.
Illustrative investigation
A request value reaches a database operation
01 / Input
Where the application receives the value
02 / Transformation
How it is changed, checked or passed onward
03 / Operation
The security-sensitive use the reviewer must inspect
Location
File & line
Assessment
Severity & confidence
Coverage
Method & limits
Conceptual example. Flow evidence is available only for supported analysis paths.
01 / Source-code analysis
Follow a finding from input to security-sensitive operation
For supported rules and languages, analysis can connect request-controlled values, transformations and security-sensitive operations. Review the source and sink locations, line ranges and available trace alongside the finding. Other checks use syntax, text, missing-control or ordered-event evidence; the result should be interpreted according to the method that produced it.
This matters when reviewing injection, unsafe file access, deserialisation, credential handling or configuration mistakes. The relevant question is how the application uses the value, not simply whether a dangerous function name exists in a file. A reviewer still needs to confirm runtime configuration and application-specific protections.
02 / Source-code analysis
Separate severity from confidence and coverage
Severity describes potential impact. Confidence describes the support for the finding. Coverage describes what the scan managed to examine. Those are separate signals: an uncertain high-impact candidate deserves investigation, while a short report from a partial scan cannot be treated as a complete assessment.
Skipped or unsupported work, unresolved inputs and time budgets remain visible. In CI, incomplete analysis and threshold failures have different exit codes, and both can occur in the same run. Teams can keep that distinction in their release decisions instead of equating an empty finding list with success.
03 / Source-code analysis
Keep the review useful after the first scan
An uploaded run gives reviewers a shared place for assignment, comments, dispositions and follow-up. Matching identities help reconcile later scans with existing records. Compare the appropriate repository and scan scope before treating a finding as newly introduced or resolved.
Source analysis is bounded. Selected helper and context checks do not amount to unrestricted whole-program reasoning, and static analysis does not execute a deployed application. Use the language and framework coverage reference when selecting a pilot, then combine findings with repository tests and engineering review.
Reviewable output
The information behind the next decision.
Local SAST with affected locations, supported flow evidence, severity, confidence and explicit analysis coverage.
| Evidence | Use in review | Follow-up |
|---|---|---|
| File and line range | Locate the affected operation in the scanned revision | Confirm the source revision and surrounding code |
| Flow and method, where supported | Understand why the scanner connected an input to an operation | Check application-specific validation and runtime assumptions |
| Severity and confidence | Prioritise impact while recognising uncertainty | Record applicability and remediation reasoning |
| Coverage and limitations | See partial, skipped or unsupported work | Run the missing checks or document the remaining assessment |
Put it to work
Start with one representative repository.
Establish a baseline
Choose a representative repository and run the relevant checks locally. Review coverage before deciding which finding categories should block delivery.
Investigate and fix
Read the trace and remediation guidance, inspect the surrounding implementation, and make a change with the repository's own tests.
Rescan and retain the decision
Rescan the final revision. Upload when shared triage is needed and keep any accepted or unresolved risk visible to the release owner.
magdox scan .
magdox scan --details .
magdox scan --format html --out review.html .
magdox scan --repository payments-api --upload .Requires an authorised CLI and compatible engine/rule bundle. The last command uploads findings; earlier commands produce local results. The HTML report is a local artifact and must be shared deliberately.
Before you start
Scope and practical questions.
Does analysis need my source uploaded?
No. Source analysis runs locally. Optional result uploads use metadata by default. Matched snippets require both repository permission and the operator's explicit include-code choice.
Does the scanner prove the application is secure?
No. Findings and analysis coverage are evidence for review. Runtime controls, unsupported frameworks and business-specific requirements may need other tests.
Explore Code Security
Dependency security
Review known vulnerabilities, malicious-package indicators and unresolved dependency versions from the repository's own manifests and lockfiles.
Secrets & configuration
Review source, infrastructure definitions and delivery configuration locally, with redacted secret findings and file-level context.
Software, crypto & AI inventory
Build software, cryptographic and AI inventories locally, then find recognised components across the repositories you choose to upload.
Code Security · next step
Evaluate the workflow on your own code.
Use a repository your team understands, review the findings with its engineers and decide how the result fits your delivery process.
14-day self-service trial. Card required; cancel before the trial ends to avoid the first charge.