Yes, if you have the source and the agreement allows it. The cleanest approach is to set the expectation before work starts, scan each delivery as part of acceptance, and agree how findings flow back to the contractor. Ask your own advisors about contract wording, since this post is not legal advice.
Why scan delivered code
You will run and maintain what the contractor writes, so its flaws become yours. NIST's Secure Software Development Framework says code review and analysis practices can cover third party code and reusable code modules written in house, which fits this case. Acceptance is the natural checkpoint, because the contractor is still engaged and fixes are cheap.
Set expectations early
Raise scanning in the statement of work, not at delivery. Useful items to agree on:
- Which analysis will be run on each delivery, and which rule set.
- What counts as a blocking finding for acceptance.
- How the contractor receives findings, for example through your tracker.
- How long they have to respond or fix.
- What happens when they believe a finding is a false positive.
Do not promise a zero finding delivery. Static tools report possible issues, and OWASP notes they often produce false positives. Agree on a triage process instead.
A delivery workflow
| Step | Owner | Note |
|---|---|---|
| Contractor delivers to a branch or repository you control | Contractor | Avoid scanning only a zip file if a repository is possible |
| Run the agreed scan and dependency scan | Your team | Save the exported results with the commit hash |
| Triage the results | Your team, with contractor input | Mark fixed, false positive or accepted |
| Return confirmed findings | Your team | Include code location and the weakness type |
| Rescan the fix | Your team | Confirm closure before acceptance |
Keep results tied to a specific commit. If the contractor delivers again, you can compare the two scans and see what changed.
Ask them to scan first
A good arrangement is to ask the contractor to run the same tool or an equivalent before delivery. That moves the common findings earlier. You still scan on acceptance, because it is the independent check.
Handle the awkward cases
- No source delivered. You may only receive compiled output. Some tools can analyze it, though findings may be harder to fix. Ask your tool vendor what is supported.
- Contractor uses a different language or stack. Check that your scanner supports it before you commit, not after delivery.
- Disagreements about findings. Use a written record of why a finding was accepted and who approved it. Keep it with the delivery.
Keep ownership clear
After acceptance, the code is in your repository and in your scan cycle. Findings that appear later are yours to triage. Make sure someone on your side owns that code, so it does not sit in a corner with no reviewer.
A worked example: a three milestone engagement
A company hires a contractor to build an internal reporting tool in three milestones. The scenario is illustrative.
Before kickoff: the statement of work lists the analysis steps. Each milestone delivery goes to a repository the company controls. The company will run its standard code analysis and dependency scan on every delivery. Blocking categories are defined as injection patterns in internet facing code, hardcoded credentials and components with a known critical vulnerability that is reachable. Everything else is triaged but does not block acceptance.
Milestone one: the scan finds two injection patterns and one outdated library. The company sends the findings to the contractor through the shared tracker. The contractor fixes two and explains one as a false positive, with a code reference. The company agrees after reading the code. The record shows the decision and the date.
Milestone two: the delivery adds a file upload feature. The scan reports a path traversal pattern. The contractor fixes it, and a rescan confirms.
Milestone three: the scan is clean for blocking categories. A few low severity findings remain on a list for the maintenance period. The company accepts the delivery.
At the end the company holds three scan exports, three triage logs, and a clear history of what was changed and why.
Responsibilities by party
| Task | Company | Contractor |
|---|---|---|
| Define blocking categories | Owns | Reviews and agrees |
| Run acceptance scan | Owns | Provides build instructions |
| Fix confirmed findings | Reviews | Owns |
| Decide on disputed findings | Owns final call, with evidence | Provides explanation |
| Keep records | Owns | Keeps own copy if desired |
Contract points to discuss with your advisors
This is not legal advice, and wording belongs with your counsel. Common topics are access to source and build instructions, the right to analyze delivered code, how long the contractor must fix confirmed findings, who pays for rework due to findings, and what happens to the contractor's copy of the code after the engagement. Raise them early. Terms agreed after a dispute begins are harder to get.
Technical requirements to ask for
- A reproducible build, with documented steps and dependency sources.
- A lock file or equivalent for dependencies, so the dependency scan matches what ships.
- No secrets in the repository, and a stated way to supply configuration.
- Code delivered through version control with meaningful history, not only as an archive.
- A short README explaining structure and how to run tests.
These help the scan and also make the code maintainable.
Reading the first scan with the contractor
Invite the contractor to a short call after the first scan. Walk through three findings together. They will often point out that a finding is a false alarm because of a custom helper, or confirm and fix it on the spot. Doing this once sets a tone: findings are a shared work item, not an accusation. It also teaches you how the contractor writes code, which helps in triage.
Dealing with third party code in the delivery
Contractors often include libraries and sometimes copied code. Ask for a list of third party components and licenses. Run dependency scanning to check known vulnerabilities, and keep the inventory as part of the delivery record. If copied code is present, decide whether it should be scanned as your own code or excluded as vendored code, and record the decision.
After handover
Assign a named maintainer on your team before the contractor leaves. Rerun the scan on the final merged state, store the export, and schedule the repository into your regular scans. Without that step, the delivery becomes an orphan that nobody monitors.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a check result appears on a change and how a reviewer can respond, which mirrors acceptance of a delivery.
Quick check
Do I need the contractor's permission to scan code they deliver?
Usually the delivered code is yours to analyze, but terms vary. Confirm with your own legal advisor and set expectations in the agreement.
Should acceptance depend on a clean scan?
Define blocking categories instead of a clean result. Tools report possible issues, so a triage process is more workable than zero findings.
What if the contractor says a finding is a false positive?
Ask for a code reference that explains why. If it holds up, record it as a false positive with the date and approver. If not, keep the finding open.
Safeguard offers policies and gates, SBOM and dependency scanning, and a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
