Corporate Software Inspector: The Scanner That Became Software Vulnerability Manager

Corporate Software Inspector was a security tool that scanned a company’s computers, listed the programs installed on each one, and flagged the programs that carried known security flaws with no patch applied yet. A patch is a small update the maker of a program releases to fix a flaw. The tool paid special attention to third-party applications, meaning programs that do not come from Microsoft, because those updates were the ones IT teams missed most often.

Secunia, a security company in Denmark, launched the first version in 2008. Flexera acquired Secunia in 2015, and in May 2018 it renamed the product Software Vulnerability Manager, the name Flexera still uses on its site today. So when an old audit checklist, support forum or job post mentions Corporate Software Inspector, it means the tool that now answers to that newer name. This guide explains what it did, how the scanning worked, and the job it did that every IT team still has to cover somehow.

The problem it solved: the third-party gap

A work computer patches itself in two very different ways. Microsoft’s own software, Windows and Office, updates through Microsoft’s channels, and most companies automate that part well. Everything else on the machine updates itself, or does not. A browser, a PDF reader, a video player, Java, chat apps and small utilities each run their own update routine, and each one waits for a user who keeps clicking Later.

Attackers know this. Most break-ins through software do not use a brand new flaw. They use a vulnerability, a weakness in a program that an attacker can exploit, that the maker has already fixed in a newer version. Once a fix ships, the flaw is public knowledge, so every machine still running the old version is a door with a published map. Security people call the fix a patch, and the gap between a patch existing and a machine receiving it is where these tools earn their keep.

One corner of the problem has no patch at all. Programs reach the end of their supported life, and the maker stops fixing them, yet copies linger on machines for years because one team still opens them. No update can save those. The only safe move is removal or isolation, and a good scan flags end-of-life programs separately from merely outdated ones, because the answer is different: update this one, delete that one.

The hard part was never knowing that a flaw existed. It was answering a blunt question across thousands of machines: which computers still run the vulnerable version of this program? A spreadsheet cannot answer that, and neither can walking the floor. That is the question Corporate Software Inspector was built to answer, and the question the whole software vulnerability management category still answers today.

How Corporate Software Inspector worked

The scan came first. Flexera’s documentation describes two ways to look at a machine. A small agent program, csia.exe, could sit on the machine and scan it from the inside. Or the console could scan machines remotely over the network, installing nothing on them, an approach Flexera calls an agent-less or remote scan. Either way, the scan produced the same thing: an inventory of installed programs with exact version numbers.

Version numbers decide everything in this job, because a flaw usually affects only certain versions of a program. That obsession with the exact version mirrors the discipline developers apply to their own code with version control systems, except here it covers every program on every desk, not one project. The scan results then met the second half of the product: the vulnerability intelligence.

That intelligence came from Secunia Research, the research team Flexera still runs today. Its specialists test and verify public vulnerability reports, reject the ones that do not hold up, and publish advisories with a criticality score and attack details, a process Flexera describes on its Secunia Research page. The tool matched each installed version against those advisories, so a machine did not just report what it ran. It reported which of those programs were known to be dangerous, and how dangerous.

Ranking mattered, because no team patches everything on day one. Advisories carried criticality scores, and the modern product adds threat intelligence scoring that weighs how likely a flaw is to be exploited, so the queue starts with the flaws attackers actually use. Then came the fix. Flexera’s release notes describe the product as combining vulnerability intelligence, vulnerability scanning and patch creation with patch deployment tool integration. In practice, the tool built ready patch packages for third-party programs and published them through Microsoft WSUS or System Center Configuration Manager, the systems companies already used to push Microsoft updates. A later rescan closed the loop and proved the fix had landed.

The console side mattered as much as the scan. Flexera’s product page for the current version stresses reporting: dashboards that show the vulnerability status of the whole estate, progress on remediation, and reports shaped for compliance checks and regulations. That paper trail is not decoration. When an auditor asks how the company knows its machines are patched, the report is the answer, and it comes from scan data rather than from a spreadsheet somebody updated by hand.

Sensible teams did not push a fresh patch to every machine at once. They tested the update on a small group first, watched for breakage, and only then rolled it out, the same careful order taught in software testing basics. A patch that breaks the program it protects trades one problem for another.

Agent or agent-less: two ways to look at a machine

Flexera’s scanning documentation spells out the choice. The agent can run in three modes: on a single host, in network appliance mode, or from the command line. In appliance mode, one agent scans whole networks on a schedule, finding targets by IP range or host name, which suits buildings full of desktops. A local agent suits machines that come and go, because the scan runs on the machine itself.

The agent-less route installs nothing. The console reaches across the network and inspects the machine using standard operating system services. On Windows that route has homework: file sharing must be on, and the account running the scan needs local administrator rights on every target. It also needs the target awake and on the network when the scan runs. Neither route is better in general. Agents cost an install and upkeep on each machine. Remote scans cost network access and permissions. Most estates end up using both.

There is a third path for estates already run through SCCM. Flexera’s documentation describes packaging the agent inside SCCM itself and running it as a recurring job, weekly in its example, so scans ride on infrastructure the company already manages. The results still land in the same console, whichever route collected them.

From Secunia CSI to Software Vulnerability Manager

The research team came first. Flexera says the Secunia Research team traces its start to 2002, verifying vulnerability reports out of Denmark. Six years later Secunia built the scanner on top of that intelligence and launched Corporate Software Inspector in 2008, in Flexera’s own words a scanning engine to determine the patch status of applications. Customers shortened it to CSI, and the name stuck for a decade.

In 2015 Flexera, a company known for software asset management, acquired Secunia. The fit was natural: one side of the house counted what software a company owned, the other side judged how dangerous that software was. Under Flexera the product kept growing past inspection. It packaged patches, published them into WSUS and SCCM, and reported on the whole process.

That growth is why the name changed. In a blog post announcing the rename, Flexera said the old name no longer reflected what the solution had become, and that the change would take effect with the release scheduled for the first half of May 2018. The functionality and the interface stayed the same, Flexera noted. Documentation from 2018 onward introduces the product as Software Vulnerability Manager, formerly Corporate Software Inspector, and Flexera still sells it under that name on its product page, with patch automation and threat scoring added since.

The job, in plain words, outlives the name

Strip away the brand and Corporate Software Inspector did a job with a plain description: know what software you run, know which of it is known to be broken, fix the worst of it first, and prove you did. The industry calls that loop software vulnerability management, and it is now a standard part of how companies protect themselves, whether they buy this product, a rival, or build the loop from parts.

Judged as a category, a good tool for this loop needs four things. It needs coverage of the third-party programs people actually install, not just the operating system. It needs verified intelligence, because raw flaw feeds contain duplicates and errors that waste patching time. It needs ranking that reflects real attacks, so a flaw with working exploit code jumps the queue. And it needs a delivery path into the tools that already push updates, plus reporting an auditor can read.

The loop also settles an old office argument. Security teams find risk for a living, and IT operations teams keep machines running for a living, and the two groups often talk past each other about whose queue a patch belongs in. A shared scan, a shared ranking and a shared report give both sides the same facts. The argument shrinks to timing and testing, which is where it belongs.

The honest limits matter too. A scanner like this finds known flaws in programs it covers. It cannot flag a flaw nobody has reported yet, and it cannot see a machine it cannot reach or scan. Some findings have no patch at all, so the fix is to isolate or remove the program. And before any fix rolls out, teams rehearse it against stand-ins for the real systems, the same thinking behind test tools such as Rational Test Virtualization Server, so a cure never debuts in production.

There is also a quieter benefit that made the old product popular with the people who count software for a living. The inventory a security scan builds doubles as an asset list: what is installed, where, and at which version. Even teams that never suffered a breach used that list to clean up unused programs and to walk into audits with answers instead of guesses. Readers who want the isolated test side of this work can start with our explainer on what a sandbox environment is.

If you still meet the old name

Plenty of paper still uses the old name: old procurement records, support threads, certification study notes and a decade of blog posts. None of it points to a different product. Flexera’s current documentation covers Software Vulnerability Manager, in cloud and on-premises editions, and that is where setup guides, scanning requirements and release notes live now. Anyone evaluating the tool today should read those pages, not a CSI-era review, because the product has gained automation and threat scoring that the old name never had.

Conclusion

Corporate Software Inspector was the right name for 2008, when the product’s job was to inspect. By 2018 the job had grown into managing the whole path from a published flaw to a patched machine, and Flexera renamed it Software Vulnerability Manager to say so. The name on the box changed. The question the tool answers has not: which of our machines still run software that attackers already know how to break?