Logs are an essential tool for developers, offering insights into application behavior, performance, and debugging processes. However, they also represent a critical security vulnerability if mishandled. A recurring issue plaguing the software supply chain is the inadvertent dumping of sensitive information, such as credentials and tokens, into log files. Despite being a well-documented bad practice, this issue persists—causing significant breaches and escalating the risks of supply chain attacks.
The “Oops” Moments We Can’t Afford
Leaking sensitive data into logs isn’t new. It’s been acknowledged as a serious concern for nearly two decades. One of the earliest Common Weakness Enumerations (CWE-532: “Information Exposure Through Log Files”) identified this issue in 2006. Yet, the problem remains alarmingly widespread.
Here are some notable incidents:
- In 2018, Twitter (pre-X rebranding) urged hundreds of millions of users to reset their passwords after a developer accidentally logged plaintext user credentials in their internal systems.
- In 2022, a major breach exposed thousands of GitHub, AWS, and DockerHub tokens within Travis CI logs, paving the way for potential supply chain attacks.
- More recently, another significant event emerged: sensitive data dumped into logs by developers once again facilitated an avenue for cyberattacks.
Why Does This Happen?
The root cause lies in developers’ priorities and workflows:
- Developer State of Mind: Most developers aim to ensure that applications work as expected. Logs are often used to troubleshoot issues quickly, sometimes at the expense of security best practices.
- Ease of Debugging: When applications don’t behave as anticipated, logging environment variables or edge-case data (e.g., failed login attempts) becomes a quick and simple method for identifying issues. Unfortunately, these logs can unintentionally include sensitive information, such as personally identifiable information (PII), secrets, or credentials.
Logging is convenient, but when secrets are captured in plaintext, the consequences are dire.
Introducing the “Security-Included” Philosophy
Borrowing inspiration from Python’s “batteries included” philosophy, we advocate for “security included”: embedding security practices into tools and frameworks by default. Developers shouldn’t need to think about implementing security — they should be able to focus on building software while automated systems handle best practices.
How It Works
Well, we’d love to tell you…but this is the content for our Black Hat Europe talk on Wednesday, December 11, 2025 at 10:05 AM. Please join us, ask questions, and provide feedback! This open-source project will also be released in the Black Hat Arsenal so you can try “Security Included” with your own investigations.
Can’t make it to the event? We’ll update the content on the OX website after the event so you can read more about this open-source capability and protect your applications from data leaks and accidental exposure.
