The use of third-party code in a majority of enterprise applications and the introduction of poorly-vetted code into production are increasing the risks of Shadow Code- unauthorized and insecure code deployed in production. Ameet Naik, Security Evangelist at PerimeterX, details seven main indicators of your organization being at risk from shadow code.
Your developer team is sprinting to deploy a new e-commerce website. They need icons for buttons and animations. Naturally, they search online for the many sites that offer free or cheap icons since your budget is not infinite. Unfortunately, if they land on the wrong icon marketplace, they may get more than what they bargained for – a skimmer that injects a fake payment page into your website and steals customer data.Â
In May 2020, Malwarebytes detailedOpens a new window how a Magecart gang pulled off this stunt by scraping the icons from a legitimate site and modifying them to contain scripts to inject forms and code into front-end web application code. The malicious hackers used a complicated but increasingly common practice called “steganography†to obfuscate scripts in images. The dev team never thought to put the icons through a code review process or to closely vet the identity of the icon site. This is a classic case of “Shadow Code†– a growing problem that all IT and information security teams should know.
What is Shadow Code?
Shadow Code is to JavaScript as Shadow IT is to rogue SaaS applications. Shadow IT occurs when employees adopt and use software and cloud services that are not reviewed, approved or monitored by IT. Shadow Code starts to persist when developers add third-party code to production applications or development processes without proper safety validation.Â
Third-party libraries and packages often make up a high percentage of front-end code, as well as the middleware code that connects the front-end of an application to the back-end databases and core application servers. Modern applications, in particular, may contain as much as 70% of third-party code. This third-party code accelerates and simplifies development by providing critical functionalities such as payments, maps, responsive design elements, and animation. It also improves application performance by offloading compute-intensive functions to third parties.Â
For front-end code, this is mostly the addition of unapproved and unreviewed JavaScript libraries and services, which may be open source and free, or may be paid services. For other application code, this can be adding open source NPM or PyPI packages. In both cases, developers may be mistakenly including third-party code with names that closely resemble legitimate packages (a practice called typosquatting). Or they may be adding third-party code maintained by developers and organizations that do not follow best security practices and are compromised during updates or code changes.
Learn More: No Code Tech Is Helping Businesses Adjust to New Realities
Seven Signals Of Shadow Code Risk
In our research, we have identified common patterns that indicate a potential Shadow Code problem. Here are seven specific signals that your web applications may be at risk.
1. You have no accurate inventory of what third-party code is running on applications
Just as you need an accurate inventory of all third-party software and services your employees are using, security, IT, and development teams need an accurate inventory of all third-party elements deployed in applications. This may sound daunting but as the icon example demonstrates, even small and seemingly innocuous elements can introduce harmful scripts into your applications and cause big problems like loss of PII and customer financial data.
2. You are deploying at high velocity but only reviewing application security annually or semi-annually
Many development teams are pushing new code to applications daily or even multiple times a day. This means lots of new code – and probably new first-party and third-party code – is entering your application runtime and your application supply chain. If you are deploying at high velocity, then annual or semi-annual security reviews are no longer sufficient. You need to review far more frequently. This can involve streamlining the application development lifecycle to scan for Shadow Code risks as part of the deployment process.Â
3. You do not have website security controls such as CSPs or have not properly configured your CSPs
Website security controls govern what your application can and cannot do at runtime. Content Security Policies (CSPs), for example, can limit any of the obvious risks from third-party code such as:
- Communicating with unauthorized domains
- Loading unauthorized scripts
- Injecting iFramesÂ
However, CSPs are notoriously difficult to manage and configure correctly. Sophisticated attacks can abuse commonly allowed services, such as Google Analytics for example, as an exfiltration route for sensitive data. Properly configuring CSPs for your website is an effective first step to improve security hygiene and limit the risk of Shadow Code.
Learn More: 25 Acquisitions That Spurred Innovation in IT Ops in 2020
4. You are using third-party JavaScript libraries that don’t meet basic security criteria
Your application security is only as good as the security of your third-party code. For that reason, you need to validate that whatever third-party supplier you are using for code or resources like icons meets basic security criteria such as:
- Has a security contact point (via email or Slack/RocketChat/Discord)
- Is responsive to security question on GitHub or in other channels
- Has a published security policy
- Issues regular security updates
5. You allow developers to include open source libraries in their applications without a formal review or approval process
Barriers to deploying open-source JavaScript libraries and packages are low as they cost next to nothing. Many developers also equate open source with greater security because the source code is public. That said, open source projects may have a large number of contributors with write privileges which increases the odds of accidental or malicious Shadow Code being injected into the project. So open source must be treated with the same caution as any other third-party element.Â
6. You do not have strict version control in place for applications
Version control is more than just rollback capability. It is all too common to find web applications with outdated libraries or packages with known zero-day vulnerabilities. If your organization follows secure DevOps practices, this means a rigorous and documented deployment checklist for Continuous Integration / Continuous Deployment and version control that includes a security review and QA testing in a staging environment to spot problems.Â
7. You don’t analyze application behavior at runtime to spot anomalies or suspicious behaviors
You are probably running new versions of an application in a staging environment to ensure that the new code does not break any key functionalities. However, this may not be enough to catch client-side security vulnerabilities. Many client-side attacks only execute on a small sample of users, and actively avoid loading the malicious code on anything that looks like a test or staging environment. Modern machine learning-based application security technologies can silently collect behavioral signals from actual users to identify anomalous behaviors in runtime, thus detecting and stopping malicious Shadow Code attacks in real-time.
Learn More: Building the Right Device Strategy to Manage Complex IT Environments
Conclusion: Master Shadow Code By Embracing Shadow Code
The good news is that all of the above signals are easy to remedy with improved processes or modern security and anomaly detection tech. Implementing semi-automated security reviews on all elements of an application is much easier with tools like Snyk and Sonatype.Â
Running a quick security check that each new service or library conforms to basic security standards shouldn’t slow down the application development lifecycle. Anomaly detection and identification of strange behaviors at runtime are accessible via solutions that study actual application behavior for signs of Shadow Code infiltration.Â
As long as third-party code is a critical element of applications and the rare bad apple developer has access to your application – which is to say, forever – Shadow Code will continue to be a business risk. With a modern, proactive approach to DevOps and security, you can master Shadow Code and improve application security without slowing down development or spiking costs.Â
Do you think organizations are doing enough to manage the threat posed by shadow code? Let us know your thoughts on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!