Software supply chain attacks are one of the most hardest hitting and significant threats facing organisations, yet most security teams remain unprepared to address them. As part of the Strategy and Architecture team here at Sekuro, I meet with a lot of different development and security teams. From startups and greenfield skunkworks to large complex, critical infrastructure projects and ASX listed companies. One thing they all have in common is the vast use of open-source tools, libraries, and frameworks. This is great to see, as I am a huge fan of open-source, but this comes at a risk.
OWASP-identified top critical security risk
The recently released OWASP Top 10 for 2025 validates exactly what we’re observing in the field. Software Supply Chain Failures has been elevated to the number three position, expanding beyond just vulnerable and outdated components to encompass the entire ecosystem of software dependencies, build systems, and distribution infrastructure. Whilst this category has the fewest occurrences in current testing data, it also has the highest average exploit and impact scores from CVEs.
Complex software supply chain attacks, like the recent attack on the NPM ecosystem and the sophisticated widely used XZ Utils backdoor, can find their way into the cracks of your environment. We’re seeing organisations often miss these areas, and this is due to many reasons, but the main one is that there is often no person that sits between security and development teams in the organisation. Security requirements given to developers are usually completely detached from modern software development lifecycle (SDLC) practices, making them not practical (and often slowing development cadence). This leads to sufficient security controls not being implemented, and creates a dangerous gap where supply chain compromises can go undetected for months or even years.
The Shadow Zone – lack of visibility in development environments
What makes this particularly concerning is that many organisations have limited to no visibility into their development environments. Security teams have invested heavily in production only monitoring, vulnerability scanning, and incident response capabilities, but development and non-production environments often operate in a shadow zone. We regularly encounter scenarios where development teams are spinning up cloud resources in personal accounts, using unapproved tooling and version control systems, or working in environments that lack basic security controls like logging or network segmentation. When a compromised upstream dependency makes it into one of these development environments, there’s often no mechanism to detect it.
Supply chain attacks target development backdoors
In theory, development, testing, and production environments should be completely isolated from one another. In practice, we frequently see non-production services communicating directly with production databases, shared IAM roles across environments, and development pipelines that have write access to production infrastructure with no protection on what triggers them to run, and no visibility into the fact this is occurring.
“I want to be clear: A security policy/standard specifying that production and non-production data should not be mixed is not sufficient, and without adequate developer-centric security controls and visibility, it’s likely happening without your knowledge.”
This means that a supply chain attack targeting a development dependency doesn’t need to make it all the way to production code to cause damage. A compromised package in a development environment can become a backdoor into production systems if that environment has any connectivity to production resources.
The democratisation of coding through AI
We are also seeing the democratisation of development through AI coding assistants. Tools like GitHub Copilot, ChatGPT, Cursor and Claude have enabled and accelerated the ability to write code for people who previously wouldn’t have had the capability or bandwidth. This is genuinely exciting for innovation, but it’s also creating easily preventable security gaps at an unprecedented scale. We’re seeing proof of concepts take off and push for production releases quickly, with open API endpoints with no authentication. The storing of critical secrets in plaintext or committing them directly to source control. Junior developers are using AI to generate entire authentication systems without understanding OAuth flows or session management, leading to broken access controls.
Practical steps to address software development security gaps
The good news is that addressing these gaps doesn’t require a complete security transformation or years of effort. Based on what we’ve seen work across hundreds of organisations; here are three practical steps you can use immediately.
1. Prioritise proper environment segregation (and rip the Band-Aid off)
Treat all environments with the same security rigour from an architecture perspective. Development and staging environments should have complete network isolation from production, separate IAM roles and service accounts, and their own identity boundaries. These gaps are easy targets for attackers behind supply chain attacks like Shai-Hulud, which specifically exploited poor environment segregation to move laterally from compromised development environments into production systems. I know what you’re thinking: “We have too much technical debt,” or “The business won’t prioritise this,” or “It’ll take months to untangle.”
Proper environment segregation is one of those foundational controls that’s surprisingly quick to implement when you commit to doing it, and the security value is immediate and substantial. The longer you wait, the more complex and expensive the remediation becomes. Start with network segmentation, then tackle IAM boundaries, and finally address any cross-environment dependencies. Most organisations can achieve meaningful segregation in weeks, not months.
2. Log significantly more than you think you need
Most organisations we work with can afford to log significantly more than they currently are. We regularly see non-production environments completely excluded from SIEM ingestion, despite these environments being potential entry points for attackers. Even more concerning is the lack of logging for critical security-relevant events from systems like GitHub, GitLab, CI/CD pipeline execution logs, cloud control plane activity, and container registry access.
Using the Shai-Hulud attack chain as an example, the attackers performed extensive discovery activities, listing repositories, checking authentication tokens, and cloning private repositories. Without complete logging across your development infrastructure, these reconnaissance activities would go completely undetected. These logs are gold for detecting supply chain compromises, insider threats, and lateral movement.
Modern cloud logging and SIEM solutions have become more cost-effective, and the visibility you gain far outweighs the expense. If budget is genuinely constrained, at least ensure you’re logging authentication events, privileged access, and any cross-environment communication across all your environments.
3. Champion (or hire) the Security-Development bridge
This is perhaps the most critical recommendation. Champion or hire someone who wants to sit between security and development. This role, whether you call it DevSecOps Engineer, Security Engineer embedded with development, or Platform Security, is critical and often overlooked in favour of hiring more developers or traditional security analysts.
Many organisations already have this person hiding in plain sight. You know the one: that engineer who’s always asking about security implications in design reviews, who’s built half the internal tooling that everyone relies on, and who somehow understands both the OWASP Top 10 and your Kubernetes architecture. That’s your 10x engineer, and they’re probably underutilised because they’re stuck writing features instead of building security into your platform. Identify and empower them, or if you genuinely don’t have this person, hire for it.
The horizon view – industry landscape, best practices and a pragmatic roadmap
Having the internal talent is one piece of the puzzle, but it needs to be backed by a solid understanding of the security and development environment, the industry landscape and what best practices are actually practical to implement. The most useful way is to have seen what works, what doesn’t across a broad range of industries so you can plan the long term roadmap and approach that will work for your organisation.
I have the pleasure of doing this as the lead in Sekuro’s Strategy & Architecture DevSecOps practice on a daily basis. Our team does this by working with both your security and development teams to establish shared goals, create the communication frameworks that are currently missing, and build the bridge whilst you develop internal capability. This isn’t about outsourcing the problem; it’s about having someone who’s done this before guide both teams through the cultural and technical changes required. We translate security requirements into developer-friendly workflows, recommend the right tooling, and establish the processes that allow security and development to move at the same pace.
Security doesn’t slow down development cadence when it’s done and invested in properly. Once you have the right people combined with the right roadmap and approach, next is the right tooling. Join me on my next blog where I’ll discuss what we’ve seen work best, and what some alternative approaches exist for cost-constrained organisations.
Moving forward – closing the gap between Security and Development
Software supply chain security doesn’t have to be an overwhelming challenge. These attacks are succeeding for surprisingly simple reasons. Organisations have blind spots in their development environments, security and development teams struggle to communicate effectively with each other, and most organisations don’t know where they stand from a security perspective. The gap between security and development teams has created the perfect environment for compromised dependencies to slip through undetected and cause significant damage. Fix the communication problem, gain visibility, and suddenly these attacks become much harder to pull off.
If any of these sound familiar, Sekuro can help:
- You’re unsure what your developers are building, where they’re deploying it, or what cloud resources exist across your organisation
- You’re concerned about shadow development environments, personal cloud accounts, or unapproved tooling creating security blind spots
- You’re struggling to implement proper environment segregation or uncertain about your overall cloud architecture security posture
- Security and development teams aren’t aligned, leading to friction, delays, and security being treated as a blocker rather than an enabler
- You need help defining security requirements that work for development teams rather than against them
- You want to establish shared goals and an operating model that bridges the gap between security and development
- You want to build a comprehensive DevSecOps strategy and roadmap that integrates security into your development workflow without slowing down delivery
- You’re dealing with technical debt and need a pragmatic roadmap to improve your security posture incrementally
- Your organisation needs cultural change around security, but you’re not sure how to shift from a “security says no” culture to one where security and development work collaboratively
Get in touch with us to discuss how we can help secure your software supply chain and cloud environment without hindering innovation.
