This article is based on guidance originally published by Veracode. The original source link is veracode.com.
A Real-World Warning: Backdoors in Outsourced Code
Police in the Netherlands contacted more than 20,000 people suspected of having their personal data stolen by a malicious web developer. The developer had reportedly built deliberate backdoors into applications he created as a contractor for various businesses. According to allegations, he used the stolen data to make unauthorized online purchases, open gambling accounts, and impersonate victims’ family members.
This case is a stark illustration of what can go wrong when organizations outsource application development without adequate security controls. The risk is not purely theoretical — it is operational, legal, and reputational.
Why Outsourcing Introduces Security Risk
Outsourcing development offers genuine advantages: cost savings, faster time-to-market, and the ability to scale engineering capacity without permanent headcount. But it also means handing over a critical part of your software supply chain to people you may not know well.
Key questions every organization must ask before engaging external developers include:
- Is this contractor or agency familiar with secure coding best practices?
- Have they been independently vetted by a credible third-party security firm?
- Could they introduce intentional vulnerabilities — such as backdoors — without your knowledge?
- Do you have the processes in place to detect such tampering after delivery?
The software supply chain is increasingly a target for attackers. Outsourced code that skips rigorous security review is a liability, regardless of how competitive the price point is.
Shifting Security Both Left and Right
There’s widespread industry discussion about shifting security left — integrating it earlier in the development lifecycle rather than treating it as a final gate before release. This is valuable in Agile and DevOps contexts. However, shifting left alone is not sufficient, especially when code is developed externally.
Organizations also need to shift security right — ensuring security controls extend through QA, deployment, and runtime operations. If you only test early in the pipeline and neglect security post-deployment, you leave yourself exposed to threats introduced late in development or hidden in delivered code.
Securing the full lifecycle — from initial design to production runtime — is especially critical when you don’t control every line of code that ends up in your systems.
Six Recommendations for Securing Outsourced Code
1. Understand the Business Impact
Before outsourcing any application’s development, assess what a security breach of that application would actually mean for your organization. Consider:
- Would a breach damage the organization’s reputation or result in significant financial loss?
- Does the application process or store sensitive personal, financial, or health data?
- Are there personal safety implications if the application is compromised?
The answers should directly inform how much security scrutiny you apply to the outsourcing relationship and the delivered code.
2. Validate Partners with Independent Third Parties
Don’t rely solely on a vendor’s self-reported security practices. Require that outsourcing partners have been validated by an independent third party, and look for verifiable evidence that they use secure development tools throughout their own development lifecycle. Treat application security expertise as a non-negotiable evaluation criterion when selecting vendors.
3. Define Security Requirements in the Contract
Security expectations should not be implied — they should be contractual. Include explicit security metrics and service level agreements (SLAs) in any outsourcing contract. These requirements should be consistent with your organization’s internal security policy for applications of a similar risk classification. If you would require penetration testing for an internally built app, require it for the outsourced one too.
4. Conduct Independent Security Testing
Commission application security testing from a party that has no vested interest in the outcome — not the vendor itself, and not a firm with a commercial relationship with the vendor. Use the results to generate objective security ratings that inform whether the application is ready to accept or deploy. Static analysis (SAST), dynamic analysis (DAST), and software composition analysis (SCA) are all relevant depending on the application’s stack and risk profile.
5. Set Remediation Timelines
Testing alone is not enough — you need a structured process for acting on findings. Define clear remediation timeframes as part of your contract. These can be straightforward, such as:
- All Critical severity findings must be remediated within 7 days of discovery.
- All High severity findings must be addressed within 14 days.
For higher-risk applications, you can be more granular — for example, specifying remediation windows for particular vulnerability classes such as SQL injection (CWE-89) or cross-site scripting (CWE-79). Tying these timelines to contract terms creates accountability.
6. Implement Runtime Protection
Even after thoroughly vetting a vendor and reviewing delivered code, treat runtime protection as a mandatory additional layer — not an optional one. Technologies such as runtime application self-protection (RASP) and web application firewalls (WAF) can detect and respond to attacks against applications already running in your environment, including those you did not build yourself.
This is particularly important for third-party or purchased applications where you have limited visibility into the original development process.
The Bottom Line
Outsourcing code development is a business reality for most organizations. But cost savings mean nothing if an insecure or maliciously crafted application leads to a data breach, regulatory penalty, or loss of customer trust. Building security requirements into the vendor selection process, the contract, the testing workflow, and the runtime environment is not optional — it is the price of doing business safely in a world where software supply chain attacks are growing in frequency and sophistication.