Stop Shipping Security Debt: How to Turn a Crisis into a Secure Engineering Culture

A team works best when it can quickly find and fix system issues. Speed and accuracy both matter. Success also depends on how much risk the organization is willing to take and how much technical debt stands in the way of fixing big security problems.

Note: The first draft of this blog was written on 2nd December 2025.

The immediate Threat - Understanding React2Shell

React developers are dealing with a significant problem called React2Shell (CVE-2025-55182). It has a CVSS score of 10.0, the highest risk level. (React2Shell exploitation continues to escalate, posing 'significant risk', 2025) This Remote Code Execution (RCE) vulnerability allows attackers to run arbitrary code on your server. They do not need to log in or use complex methods; they just need direct access. The main issue is how React Server Components (RSC) and the "Flight" protocol handle data serialization and deserialization. Allowing the client to decide what code runs on the server was a mistake.

React2Shell is not the only problem. There are also Denial of Service (DoS) vulnerabilities (CVE-2025-55184, CVE-2025-67779) that can crash your servers, and a Source Code Exposure issue (CVE-2025-55183) that could leak your app’s secrets. This includes API keys, database passwords, and proprietary algorithms. (Team, 2025) These risks are serious.

Update your React and Next.js apps as soon as possible. Make sure you’re using safe versions (React 19.0.1+, 19.1.2+, 19.2.1+; Next.js 15.0.5+, and so on). If you can’t update right away, try disabling Server Functions or using WAF rules to help protect your systems.

For larger codebases, plan to update the most critical parts first. Start with the services that are most exposed or handle sensitive data, and update those before others. Use tools to scan your dependencies and patch the most severe vulnerabilities first.

From Log4j to React2Shell

If this situation feels familiar, you are not alone. I feel it too.

Remember late 2021 and Log4j (also called Log4Shell)? It started as a simple Java logging library, but quickly became a global security crisis. Just one malicious string in a log could let attackers run code on millions of systems. Log4j is so common that if you look at any enterprise system, you’ll probably find it there. (A concerning number of Log4j downloads are still vulnerable four years on, 2025)

Governments, big tech companies, and enterprises all rushed to respond. Regular work was put aside, and patching over weekends became common. For many teams, it was the first time they realized how fragile the software supply chain could be.

React is used across the modern web, especially with frameworks like Next.js. In the Java world, Log4j is just as widespread.

With Log4j, patching was not a one-time fix. Several patches came out quickly, and managing dependencies was a headache. Many libraries depended on their own versions of Log4j, which also needed updates. It took months to clean up after the first patches. (Tanaka et al., 2025)

The SolarWind cyberattack in 2019-2020 demonstrated to technical leaders that malware injection is not limited to a single point, but can occur at any stage throughout the software distribution process, including during updates and third-party integrations (2020 United States federal government data breach, 2020).

Following this, the Log4jShell issue further clarified that supply chain risks now extend from the earliest phases of software development to deployment. Together, these incidents illustrate how modern supply chain attacks have evolved: they exploit the interconnectedness and complexity of the development lifecycle, making every phase a potential target for compromise.

If there is any good news, it is that Log4j made us take software supply chain risks seriously. It was a challenging but important lesson in:

1. Knowing what’s in your stack - Software Bill Of Materials (SBOM)
2. Responding quickly to supply chain vulnerabilities
3. Treating dependencies as part of your security surface

The Cultural Problem: Security Debt

Right now, most teams are in triage mode: patch, ship, and hope they fixed everything.

It is easy to think, “We just need to patch faster next time.” But if React2Shell and Log4j have taught us anything, it is that this is not just a code problem. It is a cultural problem.

For years, many of us have been living in a “move fast and break things” mindset:

1. Ship features quickly.
2. Optimize for velocity.
3. Assume we’ll “fix security later.”

The problem is that "later" is when attackers are already in your system. It is not just technical debt anymore—it is security debt, and there is a future ransom attached to it.

To respond effectively to this moment, teams (and especially leaders) need to shift from reactive to proactive.

That means:

1. Security isn’t a checklist at the end.
2. It’s a core principle, like reliability or usability.
3. Security should be part of planning, design, implementation, deployment, and operations. This is the core idea behind DevSecOps.

And this is where engineering leadership becomes critical.

Leaders set the tone. If security is something you squeeze in at the end of a sprint or only talk about after an incident, your team will treat it exactly the same way.

If security is a clear priority, back it up with time, tools, and training so it becomes a regular habit for your team. For instance, allocate dedicated time each sprint for security-focused tasks, such as code reviews for vulnerabilities or updating dependencies, and include these activities explicitly in your project planning.

Your Leadership Playbook: How I would Build a Secure Engineering Culture

If you are an engineering leader, product owner, architect, or even a senior IC, you might be wondering, 'What should I do next?' Here is a practical playbook to help you start.

These key steps will guide you in making security part of your team's culture and processes:

1. Demonstrate a visible commitment to security at all levels.
2. Foster a culture of continuous learning and empowerment regarding security.
3. Promote cross-team collaboration to build a strong DevSecOps environment.

Your commitment to security should be visible and integrated into your strategy.

Security should not just be a slide in a presentation or a quarterly goal. Your team needs to see you treat it as a real priority. Talk about security in standups, reviews, and planning. Set aside time and budget for security work. Celebrate when someone finds a security issue early.

If you treat security as optional, the team will too.

Do not leave security until the end just to check a box. Bring up security at project kickoffs, include it in architecture reviews, and make it a regular topic in sprint reviews and retrospectives.

Remove fear. Empower your team with training and knowledge.

Fear is a short-term motivator. It creates silence, not safety.

Training should be meaningful, not just a box to check. Instead of another boring annual video, try hands-on secure coding sessions. Run threat modeling workshops or interactive exercises about dependency risks. 'Capture the Flag' is a popular way to make learning fun. You can also add bug-hunting bounties to your security events.

If you are a developer, start with secure coding, managing dependencies, and using automation. Architects should view security holistically by applying threat modeling, trust boundaries, and considering system design risks. Leaders should focus on risk framing to help everyone understand the impact and trade-offs.

Threat modeling is an exercise for finding security holes in an application and its environment. It involves creating a representation of an application with all its components, then identifying weak spots. Ideally, developers and security engineers use threat modeling throughout the software development process — before an application goes live, not just after. - Cloudflare.

Build a 'Security Champion' network. Choose motivated developers in each team and give them extra training. Make them the go-to people for security questions. Connect them with security specialists. They will be the bridge between the security team and the rest of engineering.

Create a culture where people can report issues without fear of blame. If people are afraid to admit mistakes, you will hear about vulnerabilities late, if at all, and miss chances to learn and improve.

Encourage people to report issues quickly. Treat incidents as chances to learn, not to assign blame. Hold blameless post-mortems.

Psychological safety is a hard requirement for real security.

Building bridges instead of silos is the real path to DevSecOps.

Traditionally, Dev builds, Ops deploys, and Security steps in at the end to say “no.” We need to move to a better culture where Dev, Ops, and Security share responsibility from the beginning. This is called shifting left.

Integrate security checks directly into your CI/CD.

• SAST (Static Application Security Testing) for code
• SBOM (Software Bill of Materials) list of ingredients that make up software components or SCA (Software Composition Analysis) for dependencies (e.g., automated npm audit)
• DAST (Dynamic Application Security Testing) for running apps

The sooner you find issues, the easier and less costly they are to fix. Encourage teamwork and include security in design discussions. Make sure ops and security work together on incident response. Mock drills, or game-day exercises, are a good way to find gaps in your responses. For instance, during a recent drill, our team identified a pager gap, prompting us to revise our alert protocols and improve response times. These tangible wins motivate further repetition of such exercises.

Adopt security by design. For every new feature, ask, 'What can go wrong if this is abused?' It does not have to be a deep dive every time; just be consistent.

Conclusion - The Path Forward.

React2Shell, like Log4j, shows that waiting to react to security issues does not work. Taking a security-first approach is key to keeping systems strong and earning user trust. Without user trust, your product cannot succeed.

In the future, we can expect frameworks to have stronger security features, more use of AI and machine learning for threat detection, and wider adoption of Zero-Trust architectures. At the same time, AI is making supply chain attacks worse, with malicious package uploads to open-source repositories increasing by 156% in the last year. (2024 in Open Source Malware, n.d.)

Supply chain attacks are concerning because attackers target trusted third parties, like services, updates, or tools, to get into many organizations indirectly. These attacks are sneaky. Compromised but legitimate-looking updates can cause victims to install harmful software without knowing it. Detecting these threats early is difficult, even for well-secured organizations, because malicious activity often appears normal.

The answer is not to stop innovation, but to make security a key part of how you innovate. I suggest that organizations add a structured security review at every stage of the software development lifecycle, ensuring security is considered from the start through ongoing maintenance. By setting up regular, automated security audits and applying secure coding practices every day, teams can find and fix vulnerabilities early. Looking ahead, I urge engineering leaders and teams to make security a core value and a clear step in product development. This approach not only strengthens your systems but also builds user trust and helps your organization stay strong against new threats.

References

"React2Shell exploitation continues to escalate, posing 'significant risk'." TechRadar, December 18, 2025. https://www.techradar.com/pro/security/react2shell-exploitation-continues-to-escalate-posing-significant-risk

Team, React. "Denial of Service and Source Code Exposure in React Server Components." React. 2025. https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components Accessed December 23, 2025"

A concerning number of Log4j downloads are still vulnerable four years on." ITPro, December 11, 2025. https://www.itpro.com/software/open-source/a-concerning-number-of-log4j-downloads-are-still-vulnerable-four-years-on

Tanaka, Hidetake, Kazuma Yamasaki, Momoka Hirose, Takashi Nakano, Youmei Fan, Kazumasa Shimari, Raula G. Kula, and Kenichi Matsumoto. "Mining for Lags in Updating Critical Security Threats: A Case Study of Log4j Library." arXiv preprint arXiv:2504.09834 (2025). https://doi.org/10.48550/arXiv.2504.09834 Accessed December 23, 2025

The 2025 Bybit theft of $1.5 billion was caused by a supply chain attack in wallet software that only executed when the target wallet was being used. https://thehackernews.com/2025/02/bybit-hack-traced-to-safewallet-supply.html

The 2019 SolarWinds compromise led to ~18,000 organizations being compromised. https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hackCVE-2017-5638, a Struts 2 remote code execution vulnerability that enables arbitrary code execution on the server, has been blamed for significant breaches.

"2020 United States federal government data breach." The New York Times, December 6, 2020. https://www.nytimes.com/2020/12/07/us/politics/russian-hackers-solarwinds.html

The State of Software Supply Chain 2025.https://jfrog.com/blog/state-of-software-supply-chain-security-2025/"2024 in Open Source Malware." https://www.sonatype.com/hubfs/White_Papers/2024-in-Open-Source-Malware-Report.pdf