Protecting Your Information Starts with Knowing What Your Software Is Connected To
Cyber Security Awareness Month can sometimes feel like an annual reminder to change your password, turn on MFA and stop clicking suspicious links.
Those are still good ideas for the whole year, not just October.
But for IT professionals, cybersecurity has become a much bigger conversation.
Canada’s 2026 Cyber Security Awareness Month theme is “Your best defence is you.” This year week three focuses on protecting information, including information used when banking, shopping, and accessing online services. Get Cyber Safe is encouraging organizations to think about practical ways to protect information and strengthen cyber security habits.
For IT teams, there is another practical question worth asking:
“Do we really know everything our software is connected to?”
Because your software supply chain is probably much bigger than you think.
Your Application Is Not an Island
Modern business applications rarely exist on their own.
They may connect to:
- Open-source libraries and frameworks
- Third-party APIs
- Cloud services
- SaaS platforms
- Databases
- Payment processors
- Identity providers
- Customer portals
- Vendor systems
- Internal legacy applications
- Mobile applications
- Analytics platforms
- AI services
And somewhere underneath all of that may be a 15-year-old application that nobody wants to touch because, technically speaking, it still works.
Sound familiar?
The problem is not necessarily that any individual component is insecure. The problem is understanding the relationships between those components and knowing what happens when one of them develops a vulnerability.
NIST describes software supply chain security as involving practices such as software bills of materials, vendor risk assessments, open-source software controls and vulnerability management. Its 2026 guidance on cybersecurity supply chain risk management also emphasizes documenting systems, controls, responsibilities and the people who manage and access them.
In other words, cybersecurity is increasingly about understanding the ecosystem, not just protecting the perimeter.
Vulnerabilities Are Moving Faster
There is an incredibly good reason IT professionals should care about this now.
Last week we discussed Verizon’s 2026 Data Breach Investigations Report which found that 31% of breaches began with exploitation of software vulnerabilities, making it the leading initial breach entry point for the first time in the report’s history.
Even more concerning, Verizon reports that AI is helping attackers accelerate the process of identifying and exploiting vulnerabilities, potentially shrinking defensive windows from months to hours.
That changes the economics of “we will patch it when we get around to it.”
If your team does not know what software components are in your environment, which versions are running, which systems depend on them and who owns remediation, you may already be behind the clock.
The Legacy Software Problem
This is where things get particularly interesting.
Legacy software is not inherently insecure.
In fact, many legacy applications continue to run some of the most crucial functions inside an organization. STEP Software has written extensively about this because replacing a stable legacy system simply because it is old can be an expensive and unnecessary exercise.
The risk comes when an organization no longer understands the application well enough to manage it confidently.
Maybe the original developers have left.
Maybe the documentation is incomplete.
Maybe an old framework is still being used because changing it could break three other systems.
Maybe an API was added five years ago, and nobody remembers exactly why.
Maybe the application contains third-party components that have not been reviewed in years.
All those maybes are not just technical debt they are cybersecurity debt.
STEP’s software audit approach looks beyond a simple vulnerability scan. A comprehensive software audit can examine architecture, code quality, dependencies, security vulnerabilities, performance, documentation, licensing, and maintainability.
That broader view matters because fixing the wrong thing can be almost as frustrating as not fixing anything.
Do You Have a Software Ingredient List?
One increasingly useful tool in software supply chain security is the Software Bill of Materials, or SBOM.
Think of an SBOM as an ingredient list for software.
IBM explains that an SBOM provides information about the components and relationships that make up a software product, in a machine-readable format. This inventory helps organizations identify vulnerabilities and understand where those components came from.
This becomes particularly useful when a newly discovered vulnerability affects a widely used library.
Instead of asking:
“Do we use that?”
Instead, your team should be asking:
“Where do we use that, which applications are affected, who owns them and what version are they running?”
That’s a much better question.
Your Vendor Is Part of Your Security Strategy
The software supply chain also extends to the companies building, maintaining, and supporting your systems.
When was the last time you asked a software vendor:
“How do you manage vulnerabilities in your code?”
What about:
“How do you manage open-source dependencies?”
Or:
“What happens when a critical vulnerability is discovered in a component your application uses?”
None of these are unreasonable questions. In fact, are increasingly basic questions about software ownership and risk.
About this time last year we explored this very topic in 10 Cybersecurity Questions to Ask Your Software Vendor. We included questions about secure development practices, open-source components, security testing, incident response, documentation, and post-production support.
We see these answers as a business survival guide, and the right software partner should welcome these questions.
Sometimes the Problem Is Not the Software
Here’s the uncomfortable part, sometimes the software itself is not the biggest problem.
Sometimes the problem is that nobody has a complete picture of how it works.
That could mean missing documentation, undocumented integrations, unclear ownership, outdated dependencies, or an internal team that is stretched too thin to investigate the system properly.
STEP has previously discussed the connection between software documentation and cybersecurity, and how undocumented systems can create hidden attack surfaces and make incident response much harder.
Simply put, if nobody knows how something works, nobody can confidently secure it.
So, What Should IT Teams Do?
First, take a breath, we’ve got you!
You don’t need to rip out your legacy applications or replace every vendor. And you certainly do not need to launch a six-month modernization program because someone discovered an outdated version of Java.
Instead, start with visibility.
Ask:
- What applications are business critical?
- What systems and vendors do they connect to?
- What third-party and open-source components do they depend on?
- Who owns each application and its security risks?
- When was the code last independently assessed?
- What happens when a critical vulnerability is discovered?
- Which systems have documentation, and which rely on institutional knowledge?
The answers may be reassuring; they may also reveal a few things worth investigating.
That is exactly what a good cybersecurity health check or software audit should do.
Cybersecurity Is Becoming a Software Conversation
October’s annual focus on cybersecurity awareness is a useful reminder that everyone has a role to play in protecting information. And for IT professionals, that responsibility increasingly extends into the software itself.
The applications your organization depends on are part of your security perimeter. The vendors who build them are part of your security ecosystem. The APIs and open-source components they depend on are part of your attack surface. And the legacy systems everyone hopes will quietly keep working for another five years? They are part of the conversation too.
At STEP Software, our Advisory Division helps organizations assess software, audit code, evaluate vendors and turn complicated technology problems into practical action plans. Our Legacy Software Division helps organizations stabilize, support, and modernize older systems without unnecessary disruption.
Because sometimes the first step toward better cybersecurity is not buying another security tool.
It is understanding what you already have.
Your Turn
IT professionals, what is the biggest blind spot you see in software supply chain security today?
Is it third-party vendors?
Open-source dependencies?
Legacy applications?
Documentation?
Or simply not knowing who owns the risk?
Drop us a line, let’s compare notes.
