Your Software Has a Bill of Materials. Your Workforce Needs One Too.

In December 2021, every security leader I know got the same phone call. A vulnerability in a logging library called Log4j had just been disclosed, it was trivially exploitable, and the library was inside a staggering amount of software that nobody had ever thought of as "the logging software." The question from the board was simple. Are we running it, and where?

Some organizations answered in hours. Some took weeks. The difference was not budget, and it was not talent. The organizations that answered fast had a list of parts. They knew which components were inside which applications, who had supplied each one, and what depended on what. The organizations that answered slowly had a list of products and a very long email thread.

That list has a name now. It is called a Software Bill of Materials, and I think the workforce needs one too.

What a Software Bill of Materials Actually Is

A bill of materials is an old manufacturing idea. A car maker can tell you every part in every car they shipped, where each part came from, and which assembly it belongs to. Software borrowed the idea, and in May 2021 a US executive order made it a requirement for software sold to the federal government. Two months later the National Telecommunications and Information Administration published the minimum elements an SBOM has to contain.

The list is almost disappointingly plain. The name of the component. Who supplied it. Its version. A unique identifier so two teams mean the same thing when they name it. The dependency relationship, meaning what it is part of. Who authored the record. And a timestamp, because the answer changes.

That is it. No exotic technology, no machine learning. The power of an SBOM is not the format. The power is that a dependency you have named is a dependency you can act on, and a dependency you have not named is a surprise waiting for a date.

Now Ask the Same Question About Your Workforce

Try the Log4j question in a different form. If this engineer resigns on Friday, which capabilities are affected? If this service provider's contract ends in March, which work stops? AI can now do this kind of analysis reliably; which of our tasks does that touch, and who is holding them today?

I have asked versions of those questions to a lot of leaders over the years, and almost nobody can answer in hours. Most cannot answer in weeks. It is not carelessness. It is that nothing they were ever given was built to answer it.

Every leader has three documents. The org chart shows who reports to whom. The strategy shows which capabilities matter. The budget shows what each box on the org chart costs. All three describe containers. Not one of them lists a single task.

That distinction is the whole foundation, so let me define the layers once. A capability is something your organization must be able to do: respond to incidents, secure the applications you ship, keep identity under control. A responsibility is one of the distinct things it takes before you can honestly claim that capability. A task is the smallest unit of work under a responsibility, the thing a person actually does on a Tuesday. And a tool is what the task is done with.

A job title sits above all of that and tells you none of it. Two people with the same title, the same pay band, and the same box on the org chart can spend their weeks on almost entirely different tasks. The title tells you the size of the container. It was never designed to tell you what is inside.

How Deep the List Goes

Here is what "inside" looks like for one line on one strategy slide.

Take Incident Response. Every organization has that line, or something close to it. Nobody argues about it. It gets approved and everyone moves on. Now open it up.

Underneath the line are sixteen responsibilities. Not roles, not people. Sixteen distinct things the organization has to be able to do before it can claim the line above. Underneath those are 78 tasks, four levels deep, and every one of them is on the list above, verbatim. And at the bottom, 213 named tool choices, because the work is not finished when you know what has to happen. Somebody has to know which of the twenty two data loss prevention products you actually run.

That is the real structure of one capability in CyberSN's cybersecurity taxonomy as of September 2026, with nothing removed and nothing invented.

The Minimum Elements of a Workforce Bill of Materials

So here is the proposal. Take the SBOM's minimum elements, which have already been argued over and agreed on, and translate each one from software to work.

Two of those rows deserve a second look.

The supplier row is where the word "workforce" earns its meaning. At CyberSN, the workforce has never meant employees. It means everyone and everything doing the work: permanent employees, contractors, consultants, service providers, interns, and now AI agents. Six kinds of contributor, one list. The supplier of a task can be a person on your payroll, a person on someone else's payroll, or a piece of software, and a WBOM records all three the same way, because from the capability's point of view what matters is that the task is done and who is accountable when it is not.

The author row matters because a task list written by leadership records what leadership believes is happening. One written by the people doing the tasks records what is actually happening. The gap between the two is where burnout lives.

Which Tasks Does AI Touch, and How?

An SBOM tells you what is in the software. A WBOM can tell you something an SBOM never could, because a software component does not change its nature when a new technology arrives. A task does.

So the AI question is not "how many jobs will AI replace." It is "which of our tasks does AI touch, and in which of four ways." Anthropic's economic scenarios work starts from the observation that the economy is made up of tasks, and it names the four things that can happen to any one of them. I wrote about it when the paper came out, and the four have not left my head since. Notice that the paper's unit is the task, not the job. That is not an accident.

1. Unchanged. Judgment, relationships, accountability. The tasks that were always the reason a person was in the room.
2. Augmented. The same task, done faster, by a person whose reach just extended. Most of the real change lives here.
3. Automated. A task that leaves a person's plate entirely. Which is capacity, and capacity has to be deliberately spent, or it quietly fills with whatever is nearest.
4. New. Validating, governing, directing, and overseeing work that a machine produced. None of these tasks existed two years ago.

Go back to the container. Same job title, same person, and now every task inside it carries one of those four tags.

Every one of those four is a change at the task level. Not one of them shows up on an org chart, and not one of them shows up in a headcount report. Which means that if your only instruments are the org chart and the headcount report, AI is changing your organization somewhere you cannot see.

Now put that fourth column on the WBOM. Next to every task: unchanged, augmented, automated, or new. Next to that: who or what performs it now, and who or what should perform it next.

This is the part I most want leaders to hear. The question "how many jobs can AI replace" is a question about containers, and AI has never touched a container. It reaches inside and changes the tasks one at a time. You cannot answer the AI question at the job level any more than you could answer the Log4j question at the product level. You need the list of parts, and then you need to walk it.

The Morning Something Changes

Rerun the Log4Shell test with a WBOM in hand.

A new AI capability ships and can now do a class of analysis reliably. With a WBOM, you filter the list to the tasks it touches, see who holds each one, and decide which of them to augment and which to automate, along with what the freed capacity should go toward. Without a WBOM, you send the email and wait for people to guess.

A key engineer resigns. With a WBOM, you see every task she held, which responsibilities and capabilities those tasks belong to, and which ones nobody else performs. Without one, you find out over the following six months, one dropped task at a time.

A service provider contract ends. Same list, same filter, same answer in hours instead of quarters.

And there is a human read of the same list that I think matters more than any of that. A task with exactly one supplier is a single point of failure with a name. That person is usually carrying more than anyone counted, and today the only signal most leaders get is the day they hand in their notice. A WBOM shows the dependency before the resignation rather than after it, which means you can move the task, develop a second person, or bring in an AI agent to take the repetitive half, while there is still time to do it well.

You Cannot Automate a Task You Have Never Named

Strategy is a list of capabilities. Execution is the tasks underneath them and the question of who is holding each one.

The SBOM taught the software world a lesson it resisted for years: you cannot secure what you have not listed. The workforce is about to learn the same lesson in a harder way, because the thing arriving this time is not a vulnerability in one library. It is a change to the tasks inside every job at once.

You cannot augment a task you have never named. You cannot automate it. You cannot protect the person carrying it. Start with the list.

About CyberSN Workforce Intelligence

CyberSN's Workforce Intelligence Engagement gives cybersecurity and IT leaders a task-level view of the workforce ecosystem: the tasks each capability depends on, who or what performs each one across permanent employees, contractors, consultants, service providers, interns, and AI agents, and where capacity and capability sit today.

It is built on the task-level taxonomy described above, and it measures capability coverage, capacity, maturity, redundancy, and dependencies rather than headcount. So when a task changes hands, or changes nature, leadership can see what changed and decide what to do about it.