But code depositories and libraries—whether their internal or external—can hide a danger known as shadow code.
What is shadow code?
The term ‘shadow code’ comes from the phrase ‘shadow IT’ which means to use unapproved IT software and services to help drive business operations. Similarly, shadow code means the unauthorized use of code derived from internal or external sources to help facilitate software and application development.
The use of shadow code doesn’t always imply that the code itself is malicious. For example, software developers may rely on code found in their own internal libraries in the development process. Or developers may use code found in an external depository like GitHub. The challenges with shadow code aren’t necessarily the source. Instead, the problems relate to the fact that the code itself is being used without approvals—and more importantly—without the confirmation that it’s safe, compliant, and can operate compatibly with other applications, without introducing risk.
What types of problems are associated with shadow code?
Vulnerabilities—Even the best code developers make mistakes, and if there are mistakes to be found, you know that attackers will find them. Code vulnerabilities introduce the risk of security compromise. The use of unvetted and unapproved code increases the risk that vulnerabilities may exist that a threat actor can leverage.
Malicious Intent—Sometimes threat actors intentionally build malicious code and place it in depositories and libraries with the hope that it will be used. Rogue insiders can also introduce malicious code into first-party scripts.
Incompatibility—Sometimes a business may wish to introduce a new feature onto a website, such as a chat bot. So, rather than writing the functionality from scratch, the developer (usually under pressure to get the job done quickly) grabs existing code to build out the functionality. If the developer does not vet the code to make sure it’s the latest version and is compatible with other connected applications, problems can arise. For example, in 2020 Ticketmaster UK was fined £1.25m following a cyberattack that led to a data breach. It turns out that the breach was caused by problems in a legitimate chatbot tool obtained from a third-party source, which Ticketmaster had installed on its online payments page. The threat actor was able to use code in the chatbot to connect to the customer payment system and steal sensitive information.
Where is shadow code found?
The danger with shadow code is its use without approval or authorization. Therefore, shadow code is found anywhere script is found.
- An internal repository.
- A legitimate open-source library or repository.
- Code loaded by vendors without organizational knowledge.
- Code injected by threat actors for malicious intent, such as in digital skimmers.
- Third-party plugins created for a content management system.
What types of threats are associated with shadow code?
Threat actors love to attack vulnerable client-side shadow code for:
- Malicious code injection
- Magecart attacks
- Website defacement
- Data exfiltration or compromise of sensitive organizational or customer data
- Watering hole attacks (attacking users that visit your website)
- Script attacks
- SQL injections
- Ad injections
- Malicious code insertions
- Cross-site scripting (XSS)
Ensure your website code is safe
Things organizations can do to improve their overall website code security include:
- Move security to the ‘left’—Security can’t just happen after a web application is built or installed on a system. It needs to be a part of the entire website and application development process—from beginning to end.
- Practice good patch and update management—Ensure patches and updates are applied regularly.
- Use secure software development practices—Apply best practices that enable the development of more secure application code and well as aid in the detection and elimination of errors early in the application development process.
- Audit your web code assets—Know what web code assets you own and their purpose, and regularly conduct deep-dive scans to reveal intrusions, behavioral anomalies, and unknown threats.
- Use safe libraries—Confirm the security of any external libraries by making sure they’re not on any blacklists. Regularly patch and update your internal libraries and avoid any dependence on third-party library sources.
- Be selective with third-party scripts—Third-party code is a great way to avoid the time and money associated with developing your own code, but third-party scripts can also contain vulnerabilities or intentional malicious content. Review all scripts obtained from third-party sources and make sure they are approved for use.
- Use automated monitoring and inspection—Monitoring and inspection activities are critical, but also time consuming if you don’t have an automated solution to regularly review code. A purpose-built solution that automates the process can be a fast and easy way to identify unauthorized script activity.