In early 2023, a 50‑person SaaS company that builds cloud‑based logistics tools hired a three‑person external team to accelerate a new route‑optimization module. The deliverable arrived on time, tests passed, and the product manager was ready to merge. Then a senior engineer, while spot‑checking a few functions, spotted a suspiciously clean implementation of a K‑Means clustering variant. A quick GitHub search turned up the exact same 80‑line function, down to the variable names and comments, sitting in an MIT‑licensed repository — unattributed.
The discovery didn’t trigger a legal crisis. But it did trigger a process overhaul. Over the following six months, the engineering group designed and iterated on a contractor code verification pipeline that now runs automatically on every external pull request. This is the story of that pipeline, the false starts, and the combination of tools that eventually kept unoriginal code from slipping through.
Why a Single Plagiarism Instance Changed Everything
Before the incident, the company treated contractor code like any other contribution: it went through the same code review, the same CI checks, and the same static analysis. The problem wasn’t malicious; it was that the external developers optimized for speed and reused a well‑known implementation without considering attribution obligations. The MIT license requires preservation of the copyright notice and permission statement — easy to miss, legally risky to ignore.
But the engineering manager, a pragmatic technologist with a background in distributed systems, saw a deeper risk. If they missed one chunk of copied code, what were the odds they were missing more? And what about similarity to proprietary competitors’ code, which they absolutely couldn’t ship? The team needed a systematic way to verify the originality of every line delivered by contractors, not just spot‑check once.
Building the First Pipeline: Too Much Noise, Not Enough Signal
The initial approach was to bolt on dedicated plagiarism checks. They picked Codequiry, a code plagiarism detection platform that combines AST‑based similarity analysis with web‑source scanning, and wired it into their GitHub Actions workflow. Every push to a contractor feature branch triggered a scan against a corpus of public GitHub repositories, Stack Overflow posts, and academic submission databases.
The first run returned 174 matches above an 80% similarity threshold. An intern spent a full week triaging them manually. Most were false positives: two implementations of the same well‑known algorithm (like Dijkstra’s), similar boilerplate from a popular framework, or a utility function that every Java project writes essentially the same way. The team learned that raw similarity percentage alone is useless without context.
They adjusted. They began ignoring matches in auto‑generated files (protobuf stubs, gRPC clients), standard library wrappers, and files under 20 lines. They also configured Codequiry’s web‑source detection to flag only matches where the original source had a license header that differed from what the contractor delivered — a signal that an attribution obligation might be broken. The noise dropped by 65%.
The Token‑Based Comparison That Caught Hidden Clones
Even with filtering, the team missed a subtly refactored copy of an Apache‑licensed graph traversal library. The contractor had renamed variables, reordered statements, and changed the control flow slightly — enough to evade a naive diff. Codequiry’s token‑stream comparison, which normalizes identifiers and abstracts syntax, still flagged a 94% structural match. That became the standard: if two files share a long‑enough token sequence after normalization, a human reviewer gets a notification.
Here’s a simplified view of how they integrated Codequiry’s API into their CI step:
curl -X POST https://api.codequiry.com/v1/check/start \
-H "apikey: $CODEQUIRY_API_KEY" \
-d "check_name=contractor-${BRANCH}" \
-d "language=java" \
-d "source=..." # zip of changed files
After completion, a second call retrieved matches and the CI run blocked merges if any license‑breaking match existed. A Slack notification told the reviewing engineer to inspect the flagged snippet before approval.
Layering Static Analysis for True Software Integrity
While Codequiry handled code originality and attribution, the team also wanted to ensure contractors weren’t introducing security vulnerabilities or maintainability nightmares. They already had SonarQube running on their main codebase, but the contractor branches were often excluded because the projects were short‑lived and the developer edition seat count limited. They shifted to Semgrep, an open‑source static analysis tool that could be run on ephemeral branches without per‑seat licensing cost.
The workflow became:
- Contractor pushes to a feature branch.
- GitHub Actions triggers Codequiry for similarity and web‑origin checks.
- In parallel, Semgrep scans for security rulesets (CWE Top 25, OWASP Top 10) and project‑specific patterns.
- If Codequiry flags a high‑confidence unattributed match, or Semgrep finds a critical vulnerability, the PR is blocked automatically.
The team also included an optional step: Snyk for dependency vulnerability scanning, because occasionally contractors would bring in a new library with known CVEs. That scan happened on package manifest changes.
“We originally treated contractor code like a black box — we reviewed it, but we didn’t really know its provenance. Now we have a pipeline that tells us, within 15 minutes, whether the code is original, properly attributed, and free of the security flaws we care about. It’s not perfect, but it’s saved us from two more embarrassing license violations and one critical vulnerability in the past year.” — Head of Platform Engineering
Measuring What Worked and What Didn’t
After six months, the team reviewed pipeline metrics. They’d processed 217 contractor PRs. The plagiarism detection step flagged 14 submissions with significant unoriginal code. Of those, 11 were false alarms or acceptable reuse (e.g., the contractor had written the original GitHub code themselves, or it was a permissively‑licensed snippet correctly attributed). Three were real: one more case of unattributed MIT code, one chunk of GPL‑licensed code that would have forced the company to open‑source their proprietary module, and one case of a function copied directly from a Stack Overflow answer without understanding the license implications.
The false‑positive rate sat around 0.6% per PR, down from the initial unmanageable flood. The human review burden stabilized at about 20 minutes per flagged PR for an engineer to examine the side‑by‑side snippet and decide. The team considered that an acceptable overhead for the risk reduction.
On the static analysis side, Semgrep caught 8 high‑severity vulnerabilities before merge, none of which had been spotted in manual code review. Snyk found 4 vulnerable dependencies, leading to immediate version bumps.
When the Pipeline Itself Became a Bottleneck
There was a rough patch in month three. A contractor submitted a large 4,200‑line delivery that overloaded the Codequiry web‑source scanner, causing timeouts. The team had to split the submission into smaller chunks and run the checks sequentially. They learned to ask contractors to keep pull requests under 800 lines changed — a good practice anyway.
Another friction: the pipeline didn’t stop a contractor from copying their own code from a previous company. Codequiry’s public‑web search couldn’t detect private repository clones. The team added a legal clause in the contractor agreement asserting that all deliverables were original or properly licensed, and they supplemented the technical check with a lightweight questionnaire. No tool can replace a trusted human process.
What This Means for Any Team Using External Code
The SaaS startup’s experience isn’t unique. Many organizations that engage third‑party developers, whether through agencies, freelancers, or offshore partners, face the same blind spot. The solution isn’t to ban outsourcing; it’s to build a lightweight verification layer that catches the most likely integrity issues before they become a problem.
Based on their journey, the core pieces that stuck are:
- Source‑origin scanning against public repositories (GitHub, GitLab, Bitbucket) using token‑based similarity, not just diff‑based comparison. Codequiry’s web plagiarism detection automatically identifies copied Stack Overflow posts and tutorial code.
- License‑aware matching to flag only those snippets where the copied code’s license imposes obligations that the contractor hasn’t honored.
- Selective static analysis focused on the highest‑risk security rules, run on every PR, with automatic blocking for critical findings.
- Dependency scanning for known vulnerabilities introduced by new libraries.
- A human triage step that respects the engineer’s time by minimizing false alarms through sensible thresholds and ignore lists.
For teams using Codequiry specifically, the company’s pricing plans offer API access that fits neatly into CI/CD steps like the one described. The platform’s reporting also generates compliance‑ready documentation showing that each external delivery was checked — something increasingly valuable during security audits.
Frequently Asked Questions
How can I check if a contractor’s code was copied from GitHub?
Use a source code similarity detection tool that indexes public repositories. Upload the contractor’s files; the tool will return matches with similarity percentages, line‑by‑line comparisons, and the original repository’s license. Codequiry automates this for both GitHub and Stack Overflow sources.
What’s the difference between static analysis and plagiarism detection for contractor code?
Static analysis examines the code’s structure for bugs, security flaws, and maintainability issues — it doesn’t care where the code came from. Plagiarism detection compares the code against a corpus of existing sources to determine originality and licensing. Both are essential for a complete integrity check.
Can automated checks catch refactored or obfuscated copied code?
Token‑based similarity analysis, which normalizes variable names and abstracts syntax, can often detect structurally identical code even after renaming and reordering. However, no technique is perfect against determined manual rewriting, so combining automated checks with human review remains the best defense.
How much time does it take to review flagged plagiarism findings?
With proper threshold tuning and ignore lists, our case study team averaged 20 minutes per flagged PR. The initial setup took a few days, but ongoing maintenance requires minimal effort once the noise filters are in place.