Treat the first scan as a survey, not a gate. Take inventory of languages and build setup, run one baseline scan, triage by weakness type instead of by count, and write a short risk note. Aim to learn what you now own within a week, not to fix everything.
What makes this different from a normal rollout
In a normal rollout you scan code your team knows. After an acquisition, nobody on your side knows where the odd corners are. The goal changes from "keep new code clean" to "understand the starting position." Expect a large first result and plan for it.
OWASP points out that many static tools have difficulty with code that cannot be compiled, because analysts frequently lack the right libraries, instructions or complete code. Acquired code often has exactly that problem, so budget time for build setup.
A week plan
| Day | Activity | Output |
|---|---|---|
| 1 | Inventory repositories, languages, frameworks, build tools | A one page map |
| 2 | Get builds working on a clean machine | A list of repos that build and ones that do not |
| 3 | Run the baseline scan on the repos that build | Raw findings, saved in an exportable format |
| 4 | Triage by weakness type and by exposure | A short list of themes |
| 5 | Run dependency scanning on the same repos | A separate list of vulnerable packages |
| 6 | Sample and verify ten findings | A rough sense of false positive rate |
| 7 | Write the risk note | A page for leadership |
Triage by theme, not by count
A raw count says little. Group findings by weakness type, then by whether the code is exposed to the internet. Ten injection findings in a public API matter more than two hundred findings in an internal batch script.
Then verify a small sample by hand. Pick ten findings across themes and confirm each one by reading the code. That sample tells you how much to trust the rest. It is not a statistical estimate, only a calibration.
Do not forget what SAST does not cover
SAST looks at code the company wrote. The acquired code also pulls in third party packages, so run dependency scanning separately. And SAST will not find configuration problems or access control gaps well, so flag those areas for review.
Also look for signs the scan missed things: directories that were excluded, languages the tool skipped, repositories that failed to build. Those are blind spots, and a risk note should list them honestly.
What the risk note should contain
- What was scanned and what was not.
- The three to five themes that matter most.
- What you recommend fixing first and why.
- What you do not know yet.
Avoid false precision. A note that says "we scanned nine of fourteen repositories, found injection patterns in two exposed services, and could not build three legacy ones" is more useful than a dashboard.
After the first week
Set a baseline so that the team is judged on new findings, then burn the backlog down gradually. A ratchet approach, failing only on new issues, keeps pressure on without freezing delivery.
A worked example: week one on a fourteen repository acquisition
A company acquires a small software business. Engineering receives access to fourteen repositories on day one. The numbers below illustrate the shape of the exercise and are not from a real engagement.
Day 1: the inventory shows nine repositories in two main languages, three older ones in a third language, and two that look abandoned. The team tags each by owner, last commit date and whether it is deployed.
Day 2: builds work for eight repositories. Four need missing private packages. Two have no build instructions. The team writes the blockers in the inventory.
Day 3: baseline scans run on the eight that build. Results are exported and stored with the commit hashes.
Day 4: triage groups the findings. Injection patterns appear in two internet facing services. A cluster of findings sits in a vendored library that nobody owns.
Day 5: dependency scanning runs on all fourteen, including ones that SAST could not build. This gives a first view of the unbuildable repositories, because a dependency scan often needs only the manifest files.
Day 6: the team samples ten findings and confirms seven by reading code. Three are false alarms caused by a custom sanitizer the tool did not recognize.
Day 7: the risk note says what was scanned, what was not, the main themes, and the recommended first actions.
Why dependency scanning rescues the unbuildable repos
SAST often needs a working build. Dependency scanning usually reads manifest and lock files, so it can run on repositories that will not compile. That gives you partial visibility on day five even where SAST had to wait. Keep in mind that it answers a different question, known vulnerabilities in third party packages, and not flaws in the code the acquired team wrote.
What to ask the acquired team
| Question | Why |
|---|---|
| Which services face the internet? | Sets triage priority |
| Where are credentials and keys kept? | Reveals blind spots for scanners |
| Which repositories are actually deployed? | Avoids wasting time on dead code |
| What was scanned before, and what was found? | Gives a history |
| Which known issues were deferred? | Surfaces risks nobody wrote down |
People often know about risks that no scan will show. Fifteen minutes with each team lead can save a day of analysis.
Handling the large first result
A first scan on unfamiliar code can return a large list. A few habits keep it useful:
- Do not circulate raw counts. Share themes and exposure instead.
- Mark vendored and generated code early so it does not drown the signal.
- Sample and verify to calibrate trust in the tool.
- Save the baseline, so future work is measured against it.
- Assign owners by service, even if the owner is temporary.
What not to promise in week one
Avoid promising that everything is fixed or that the code is clean. A week gets you a map, not a cure. Set the expectation that the second month is for fixing the top themes, and that some old repositories may be retired instead of repaired.
Reporting to leadership
Use a short structure: scope, three themes, recommended actions, unknowns. Add a line that says how the findings will be tracked, for example in the same issue tracker the rest of engineering uses. Leaders usually want to know what to decide, not a list of findings.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how an inventory of packages gives you a second view of the same codebase.
Quick check
Should the first scan block anything?
No. Use it to learn the starting position. Add gates later, focused on new findings.
What if half the repositories will not build?
Record them as blind spots in the risk note and plan build fixes, so the gap is visible rather than hidden.
Should we scan abandoned repositories?
Check whether they are deployed first. If not, consider archiving them. If they are, scan them, because forgotten services are often the ones nobody patches.
Safeguard offers asset discovery, SBOM and dependency scanning, and a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
