Upload a repository

The quickest way to see what Code Security finds in your code. Upload an archive of a repository and the findings appear in the console when the scan ends. The same hosted scan runs for connected code hosts and CI/CD.

Upload in the console

• In the console, open Repositories and choose Upload code (it needs the SuperUser role). Name the repository, choose a .zip, .tar.gz or .tgz of it, add the branch and commit if you like, and choose Start scan. A new repository name creates the repository with its first scan; for one you already have, you can also upload from its Scans tab.
• A single top-level folder shared by every file, like GitHub's owner-repo-sha folder, is removed so paths match the repository.
• While the archive is sent, a bar shows the percentage and the size sent, and Cancel upload stops it. The repository's Scans tab then opens, where the scan shows its steps as they happen and updates by itself: Queued (with its place in the queue), Unpacking, then each pass (Secrets, Code, Infrastructure as code, Dependencies, SBOM, Malicious packages, Cryptography, AI inventory), Saving results, and Done or Failed, with the files read so far and how long it has run. The repository's other tabs show Scan in progress with the same steps, and a message says when it finishes. Choose Results to see what it found.
• Upload the repository again after a fix, with the same branch as before, or none again: scans are compared and findings closed per branch. Findings the new scan no longer reports close on their own, separately for code, dependencies and secrets, and a finding in a file the scan did not analyse stays open with the reason.

What an archive may contain

A repository within these limits that is too large to finish in one scan's time still gives you a result: the scan stops starting new files, records the ones it did not reach and why, runs the other passes and finishes as a partial scan instead of failing.

What the scan reads

• The secrets and malware checks read every file in the archive, first: dependencies such as node_modules and vendor, build output such as dist and target, hidden folders such as .aws and .docker, test files, generated and minified files, files of any size, the printable text of binary files, and archives inside the upload, such as jar, war, whl, zip and tar.gz files, two levels deep.
• Each secret and malware finding says where its file sits: your code, a dependency, build output, a test file or inside an archive. Where it sits never lowers its severity. Credentials in a dependency's own test files, generic matches past the tenth in one file and findings past the hundredth in one file are counted in the scan's coverage rather than listed, and that file is named so its findings stay open.
• The malware checks look for install scripts that download and run code, encoded code that is decoded and run, code that reads stored credentials and sends them out, cryptocurrency miners, reverse shells, and programs committed with the source or named like another kind of file. Each finding names the file and the reason, and is a lead for review, not proof.
• Configuration rules for infrastructure as code, CI pipelines and coding agent files read every folder, hidden folders, dependencies and build output included, except a dependency's own CI pipelines, which never run in your repository.
• The code rules analyse your own code: they leave out dependencies, build output, hidden folders other than CI and coding agent folders, generated files, program source over 2 MiB and configuration or data files over 8 MiB, and hold back findings in test code. A .magdox.yml exclude applies to the code and configuration rules only.
• Nothing is left out silently. The scan's coverage counts and names every file a check could not read in full, with the reason, such as an archive over its limits, an encrypted archive entry or an archive format the scan cannot open.

What happens to your code

• The archive is stored encrypted, for the scan only.
• An isolated worker on MAGDOX's servers in India runs MAGDOX's rules engine on it: secrets and malware in every file, then code, dependencies, configuration, SBOM, CBOM and AI inventory. No AI model takes part.
• When the scan ends, whatever the outcome, the archive is deleted and the deletion is recorded in the audit log with the archive's SHA-256. Anything a failed scan leaves behind is swept.
• One exception, off by default: a Super Admin or admin can keep uploads for proofs under Settings, Data and privacy, for 1 to 24 hours. A successful scan's archive then stays encrypted for one proof at most, and is deleted after that proof or when the hours pass, whichever comes first, and never later than 24 hours after the upload.
• Only the results are kept: the findings, each with a short excerpt of a few lines around it so you can see where it is. Secrets are masked in excerpts, and an admin can switch excerpts off.