Integrations
Code size
How Trace measures the billable lines of code in your connected repositories, and how to reproduce the number yourself.
Trace measures the size of the code it covers so you can see it the same way we do. The number that matters is billable lines of code: first-party application code that contains something other than whitespace or a comment. We don't count tests, documentation, configuration and data files, or vendored and generated code.
You'll find the measurement in the Code size section of the Source code page in your dashboard (Settings, then Source code). It covers the connected repositories and uploaded code snapshots Trace scans, whichever platform they live on. Repositories you've excluded from scanning don't count, and the total updates as soon as you include or exclude one. A repository archived on GitHub is excluded when it's archived and stays in your repository list with an Archived mark; include it again if you still want it scanned and counted.
What gets counted
Every file in a repository lands in exactly one bucket. The first matching rule wins:
- Vendored & generated: vendor and codegen directories, lockfiles, minified assets, and files with generated-code markers ("do not edit" headers and the like).
- Tests: test, spec, e2e, fixture, mock, and snapshot directories, plus test filename conventions (
*.test.ts,*_test.go,*Test.java,test_*.py, and friends). - Documentation: Markdown, MDX, RST, AsciiDoc, plain text.
- Configuration & data: JSON, YAML, TOML, XML, INI, CSV, SVG, Terraform, Dockerfiles, Makefiles, CI config, schema definitions.
- Billable code: everything else. This is the code Trace actually tests for vulnerabilities.
Billable lines of code is the count of non-blank, non-comment lines in that last bucket.
Which code is measured
Each repository is measured from a fresh clone of its scanning branch (or its default branch if you haven't configured one). That's the same tree Trace scans. Only line counts are stored; the clone is deleted as soon as counting finishes.
Uploaded code is measured from the snapshot you uploaded, once it has passed the malware and archive checks. The archive is extracted with the same safety rules a pentest session uses, counted, and deleted from the measuring machine. Application builds (APK and IPA files) aren't measured: there's no source in them to count.
Measurement happens automatically: when you connect a repository, when your installation syncs, when a repository's scanning branch changes, when you include a repository in scanning again, and when an uploaded snapshot becomes ready. There's nothing to run or maintain.
To pick up recent pushes sooner, an admin or analyst can select Recalculate in the Code size section. Trace measures anything that hasn't been counted yet, re-measures repositories whose branch has moved since their last count, and leaves the rest as they are. Each organization can recalculate up to 10 times in any 24 hours.
Reproducing the number
The dashboard breaks the measurement down so it reconciles against tools you can run yourself. The underlying counter is the open-source scc, run with ignore files disabled so the count covers every tracked file. Use the same flags:
cd /path/to/your/repo
scc --no-gitignore --no-ignore --no-scc-ignore .scc's total line count matches the Total lines figure in the dashboard's "What's counted" table. (A bare scc run can come out lower: by default it skips files matched by .gitignore, .ignore, or .sccignore, including tracked files.) Your billable count is the subset of those lines that are non-blank, non-comment lines of files in the billable-code bucket. The table shows exactly how the rest of the total splits across blanks and comments, tests, documentation, configuration, and vendored code. If you'd like the exact per-file classification we use, ask us and we'll share it.