Do you know what your app is made of? How to build a parts list

If you've inherited an app from an agency, a former developer or an AI coding tool, you need a written list of what it's built from: the language version, the framework, the third-party packages and the server it runs on. Windows Server 2012 lost its last security updates on 13 October 2026, and attacks on open-source packages keep coming. That list is how you answer "are we affected?" in minutes rather than days.

This guide walks through how to build one, check it and keep it current, without turning it into a paperwork exercise.

Why does your app need a parts list now?

On 13 October 2026, Microsoft ended the third and final year of Extended Security Updates for Windows Server 2012 and 2012 R2, alongside support for the Office 2021 family and two Windows 10 2016 releases. The next wave starts on 11 January 2027 and includes Windows Server 2016.

Old in-house systems often sit on exactly that kind of forgotten server. But the server is only one layer. The code on top of it pulls in frameworks and packages that can be attacked too. TuxCare's review of the year reports that Laravel-Lang had more than 700 versions poisoned through rewritten Git tags. Laravel is a popular PHP framework used in plenty of agency-built sites and portals.

AI-built apps add their own risk. Cycode reports that nearly half of AI-generated code fails basic security tests, and cites a USENIX Security 2025 study in which 19.7% of the generated code referenced at least one hallucinated package: a dependency that doesn't exist, which an attacker can then register under that name.

If nobody can tell you what your app contains, you can't tell whether an alert applies to you.

Step 1: Get the code, hosting and logins into your hands

Before you can list anything, you need access. Make sure your business, not a former supplier or a freelancer's personal account, holds:

• the code repository (GitHub, GitLab, Azure DevOps or similar)
• the hosting or cloud account
• the domain and DNS account
• any package-registry accounts used to publish or pull private packages
• the database and any backups

If a previous agency built the app, ask them in writing for these handovers and for any list of components they hold. If they're slow to respond, that tells you something too.

Step 2: Write down the four layers your app is built on

You don't need special tooling to start. A shared document or spreadsheet with one row per component works. Capture four layers:

Your developer can pull the package layer straight from the project. These standard commands list dependencies and flag outdated ones:

## .NET
dotnet list package --outdated

## Node / JavaScript
npm outdated

## PHP
composer outdated

The NCSC is moving in this direction too. A weekly summary of NCSC activity points to new guidance on software bills of materials (SBOMs), the formal version of this list. You can start with a spreadsheet and grow into a formal SBOM later.

Step 3: Check each layer against support dates and alerts

Go down the list and mark each item green, amber or red:

• Red: out of support or affected by a known, unpatched flaw. Windows Server 2012 is now red.
• Amber: support ends within the next year, or the version is several releases behind. Windows Server 2016, with its January 2027 wave, belongs here.
• Green: supported and reasonably current.

Then do the same check whenever a security alert comes out. With the list in hand, "are we affected?" becomes a quick search rather than an investigation.

Step 4: Flag packages nobody chose

Inherited and AI-built apps often contain packages that nobody picked deliberately. Ask your developer to mark any dependency that:

• nobody on the team recognises or can explain
• has very few downloads or an unfamiliar publisher
• doesn't appear to be used anywhere in the code
• was added by an AI tool and never reviewed

Remove what isn't needed, and check that every remaining package is the genuine one from its known publisher. Given the hallucinated-package problem, this step matters more for AI-built apps than for anything else. If you're taking an AI-built prototype towards real customers, our AI app launch checklist covers this alongside other pre-launch checks.

Step 5: Agree who owns updates and how often

A list without an owner goes stale. Decide:

• who checks for updates and security alerts
• how often routine updates happen (monthly is a sensible starting rhythm)
• how quickly urgent fixes go out
• who approves upgrades that could break things, such as a new framework version

Write the answers down next to the list. If you don't have a developer in-house, this is the point where ongoing consultancy and support earns its keep.

Step 6: Keep the list alive every sprint

The worst outcome is a one-off document written during a handover and never touched again. Make updating the list part of normal development: whenever a package is added, upgraded or removed, the list changes in the same piece of work. At HeyIO we work in short sprints, and a quick dependency review at the end of each one keeps the list honest without becoming a project of its own.

It may also help with customers. The Cyber Security and Resilience Bill entered Lords report stage on 26 October, with proposed amendments covering voluntary reporting of incidents and near misses and a requirement for large businesses to report on cyber resilience plans. These are amendments, not law, but if you supply larger organisations, questions about what your software is built on may well become more common.

Your parts-list checklist

• Repository, hosting, domain and registry logins held by your business
• Language and runtime versions recorded
• Framework and version recorded
• Every third-party package listed with its version
• Server operating system and hosting recorded
• Each item marked green, amber or red against support dates
• Unrecognised or unused packages flagged and reviewed
• Named owner and update rhythm agreed
• List updated as part of every sprint

What should you do next?

Start with Step 1 this week: confirm you hold the logins. Then ask your current or previous developer for the four-layer list. If anything comes back red, especially a server still on Windows Server 2012, put it at the top of your priorities. And if you've inherited an AI-built app and aren't sure where to begin, our AI prototype to production work starts with exactly this kind of inventory.