Corporate Software Inspector: A Simple Guide

Written by Ahmad Jajja · Reviewed by Amir Iqbal · June 13, 2026

Most companies know which computers they own, but far fewer know exactly which software runs on each one, which versions are installed, and which of those versions contain known security flaws. That gap is dangerous, because attackers do not need a brilliant new trick when an old, unpatched program already leaves a door open. A patch, which is a fix released by a software vendor for a flaw or a bug, closes that door, but only if the team knows the vulnerable program is there in the first place. Corporate Software Inspector, usually shortened to CSI, was a product built to close exactly that gap for large organizations.

CSI began as a product of Secunia, a Danish company known for vulnerability research, which is the work of finding, verifying, and describing security flaws in software. Flexera acquired Secunia in 2015 and continued the product under the Flexera name, as Flexera Corporate Software Inspector. Later, Flexera folded the capability into its Software Vulnerability Manager line, which is the successor name teams should search for today. This guide therefore explains CSI as a real, verifiable product with a clear history, and it also tells you where its work lives now, so you do not waste time shopping for an old product name.

In one sentence, CSI scanned company computers, built a complete inventory of installed software, matched each program against verified vulnerability intelligence, ranked the risk, and helped teams deploy patches. That sentence hides a lot of careful work, from authenticated scanning to patch creation for programs that vendors do not patch through standard channels. This guide unpacks each step, explains who benefited most, and shows how the same discipline works in modern vulnerability management. If you are new to the wider testing field, our guide to the basics of testing software will help you place security scanning beside functional testing.

Why Outdated Software Is a Security Problem

Software flaws are not rare, and they are not only found in obscure tools. Browsers, document readers, media players, chat apps, and developer tools all receive security fixes on a regular schedule, because researchers and attackers keep finding weaknesses in them. When a vendor publishes a fix, the details of the flaw often become public soon after, which means attackers can build an exploit, which is a method that takes advantage of a flaw, and scan the internet for computers that still run the old version. The window between a fix being published and a company installing it is therefore a window of known risk.

Large companies struggle to close that window because their software estate is messy. One department runs an old version of a document reader because a business process depends on it. Another department installed a free utility years ago and forgot about it. Laptops that travel, contractors who bring their own machines, and servers that nobody owns anymore all add to the sprawl. A team that relies on asking users to update their own software will always miss machines, and a team that only patches the operating system will miss the third party programs, which are programs made by vendors other than the operating system maker, where many flaws actually live.

That is why inventory comes before patching. You cannot fix what you cannot see, and you cannot prove to an auditor that you fixed it without a record. A vulnerability scanner gives the team a single, current list of what is installed, what is outdated, and what is risky, so patching stops being a guessing game and becomes a planned job with owners, deadlines, and proof. CSI built its reputation on the accuracy of that inventory, because a scanner that reports false programs or misses real ones wastes more time than it saves.

How the Scanning Worked

CSI used authenticated scanning, which means it scanned computers with proper credentials rather than probing them from the outside like an attacker would. That approach matters, because an outside probe can only guess what is installed from network behaviour, while an authenticated scan can read the actual files on the computer. CSI inspected executable files, including program files and libraries, and matched them against file signatures created by Secunia Research. A signature is a reliable fingerprint for a specific program version, so the scanner could identify a program even when its registry entry, which is a Windows record of installed software, was missing or misleading.

The scan covered Windows, Apple macOS, and Red Hat Enterprise Linux, which is a business version of the Linux operating system, and it built an inventory of installed programs and plugins, which are small add ons that extend a larger program, such as a browser plugin for documents. That inventory was then matched against vulnerability intelligence, which is verified information about known flaws, affected versions, and available fixes. Secunia Research continuously verified vulnerabilities and the effectiveness of vendor patches, and that verification step was central to the product's claim. A scanner that merely copies public flaw lists without checking them will flood a team with noise, while verified intelligence helps the team trust that a reported flaw is real.

Scanning ran from a web based console, so administrators did not need to visit each computer in person. They could schedule scans, view results by department or by machine, and track progress over time. The scan itself was designed to be nonintrusive, which means it checked the system without changing programs or disrupting the user's work. That design mattered for adoption, because a security tool that slows computers or interrupts work will quickly lose the cooperation of the people it is meant to protect. Regular rescans after patching then confirmed whether the fix actually landed, which closed the loop from finding to fixing to proving.

Ranking Risk: Not Every Flaw Comes First

A scan of a large company can return thousands of findings, and no team can fix all of them on the same day. Ranking therefore decides the order of work, and CSI ranked findings using risk ratings and related measures drawn from Secunia advisories, which are published notices describing a flaw, its severity, and its fix. Severity alone, however, is a poor guide. A severe flaw in a program that nobody uses, on a machine that never connects to the internet, matters less than a moderate flaw in a browser used by every employee every day.

Modern ranking, and the approach CSI's successor continues, weighs several factors together. One factor is severity, often expressed with CVSS, which stands for the Common Vulnerability Scoring System, a standard method for rating how serious a flaw is. Another factor is exposure, which asks whether the vulnerable program faces the internet or only runs inside a protected network. A third factor is exploit availability, which asks whether attackers already have a working method to abuse the flaw. A fourth factor is business impact, which asks what data or service the affected machine touches. A flaw that scores high on all four factors jumps to the top of the list, while a flaw that scores high on severity alone but low everywhere else waits its turn.

That ranking discipline also protects the team from a common trap, which is fixing the easiest findings first to make a chart look good. Easy findings are often low risk, and a dashboard that shows hundreds of closed low risk items while critical browser flaws remain open is a misleading success story. Good reporting therefore shows risk over time, not only counts closed, and it highlights the oldest critical findings, the most widespread vulnerable programs, and the machines that remain unpatched after their deadline. Managers who read those views can ask the right question, which is not how many patches we shipped, but how much real risk we removed.

From Finding to Patch: The Remediation Workflow

Finding a flaw is only the first third of the job. The second third is preparing a fix that works in the company's real environment, and the third third is confirming that the fix reached every affected machine. CSI supported that full cycle, which Flexera described as assess, mitigate, and verify. Assessment produced the inventory and the ranked findings. Mitigation applied remediation, which means the action that removes or reduces a risk, usually by installing a patch or removing a vulnerable program. Verification rescanned the machines and reported the new patch status, so the team had proof rather than hope.

Patch creation was a notable strength for third party programs. Operating system vendors already provide their own update channels, but many third party vendors do not, or they provide installers that need repackaging before they can deploy silently across hundreds of machines. CSI included preconfigured patches for many common programs, which let administrators deploy a fix without building a package from scratch for each one. It also integrated with Microsoft System Center Configuration Manager, which is Microsoft's tool for managing large numbers of Windows computers, and with Windows Server Update Services, so teams could use a deployment tool they already owned instead of learning a separate one.

That integration point deserves emphasis, because patching tools fail when they fight the existing workflow. A tool that forces a second deployment system, a second console, and a second set of credentials will be bypassed by busy administrators. A tool that feeds its findings and its packages into the deployment system the team already trusts gets used. CSI's design aimed for that second outcome, and its successor keeps the same idea under the Software Vulnerability Manager name, with patch creation and deployment integration as core features rather than add ons. Flexera's own account of the Secunia acquisition describes the two Secunia products, including CSI, in the vendor's own words.

Who Benefited Most, and Who Did Not

CSI suited mid sized and large organizations with many computers, many third party programs, and a compliance duty to prove their patching. Regulated sectors such as finance, health care, and government fit that shape, because auditors in those sectors ask for evidence, not assurances. A hospital that can show a dated report of every vulnerable program, its risk rank, its patch date, and its rescan result can answer an audit question in minutes. A hospital that can only say that staff are told to update their software cannot answer that question at all, no matter how diligent its staff may be.

Smaller teams gained less from a dedicated product of this kind. A team with twenty computers, a short list of approved programs, and automatic updates already turned on for the operating system and the browser may already cover most of its risk with far simpler tools. The cost, the setup, and the ongoing ownership of a full vulnerability management product only pay off when the software estate is large enough that manual tracking fails. That judgement is worth making honestly before any purchase, because a powerful tool that nobody owns becomes shelfware, which is software bought but never properly used.

Even for large teams, CSI did not solve every patching problem. Not every flaw has a patch available, and some programs reach end of life, which means the vendor stops supporting and patching them, so the only safe action is removal or replacement. Some patches break a business application and need testing before wide release. Some machines sit offline for weeks and miss their patch window. A good vulnerability program plans for all three cases with testing, with exceptions that have expiry dates, and with a follow up list for offline machines, rather than pretending that a scanner alone makes the estate safe. Our guide to how companies connect their systems shows why testing a patch against connected systems matters before wide deployment.

Compliance, Reporting, and Audit Evidence

Reporting is where vulnerability management earns its keep with leadership and auditors. A useful report answers five questions in plain language: what software is installed, which programs are outdated or vulnerable, which flaws carry the highest real risk, what has been fixed and when, and what remains open past its deadline. CSI provided dashboards and reports that tracked patch status across the estate, highlighted end of life applications, and showed trends over time, so a security meeting could focus on the shrinking or growing risk rather than on a raw count of findings.

That evidence also supports compliance work, which means meeting the rules and standards that apply to an organization, such as payment card rules, health data rules, or internal security policies. Most such frameworks require timely patching of known flaws and a record of that patching, and they treat an unpatched critical flaw as a finding in its own right. A vulnerability management report gives auditors the dates, the owners, and the rescan proof they ask for, without a last minute scramble to gather screenshots from individual machines. Keep those reports for the retention period your framework requires, and treat a missing report as a gap, not as a filing delay. For ongoing checks after patching, teams often pair this reporting with compliance monitoring, which tracks whether controls stay in place between audits.

Public vulnerability data supports the same work from the outside. The US National Vulnerability Database, which catalogues publicly disclosed flaws, and the Common Vulnerability Scoring System, which rates them, give teams a shared language for describing a flaw to vendors, to auditors, and to each other. The National Vulnerability Database and the CVSS specification from FIRST are the standard references behind most commercial intelligence, including the verified intelligence that Secunia Research built its reputation on. When a vendor report and a public record disagree, investigate the difference before you act, because the disagreement itself may reveal a version detection problem.

What to Use Today: The Successor and Modern Practice

If you search for Corporate Software Inspector today, expect to land on Flexera's Software Vulnerability Manager, which Flexera describes as the successor that combines vulnerability scanning, intelligence, patch creation, and integration with patch deployment tools. That naming change is normal in enterprise software, where products merge, rename, and expand over a decade, but it confuses buyers who search by an old name. Start from the successor name, confirm current features and supported platforms with Flexera directly, and do not rely on old CSI datasheets for current coverage, because the program list and the deployment options will have changed since those documents were written.

Modern practice around the successor looks familiar, because the core cycle has not changed. Scan with credentials for an accurate inventory. Match against verified intelligence, not raw public lists alone. Rank by severity, exposure, exploit availability, and business impact. Test patches for business critical programs before wide release. Deploy through the tool your administrators already trust. Rescan to prove the fix landed, and report risk trends to leadership. What has changed is the surrounding landscape: cloud workloads, container images, and software supply chain checks now sit beside traditional desktop scanning, so a complete program covers those assets too, rather than treating office computers as the whole estate.

For a team starting this work from scratch, the practical first steps are modest. First, produce an inventory for one department and fix its top ten risky programs, to prove the process works before scaling it. Second, set patch deadlines by risk rank, with short deadlines for internet facing critical flaws and longer deadlines for low risk internal programs. Third, name an owner for the program and a weekly review meeting, because a scanner without an owner produces reports that nobody reads. Fourth, track the oldest critical finding as your headline measure, since that number reveals whether the program actually reduces risk or merely counts activity. For ongoing upkeep of the systems around such a program, our support and maintenance work covers the monitoring and update stages that keep an estate healthy after launch.

Conclusion

Corporate Software Inspector earned its place by solving a simple, painful problem: large companies could not see which software they ran, which versions were vulnerable, and which patches mattered most. Its authenticated scanning, verified intelligence, risk ranking, and patch deployment support turned that blindness into a managed cycle of scan, assess, mitigate, and verify. The product name has since given way to Flexera Software Vulnerability Manager, but the discipline remains the same. Know your inventory, rank by real risk, patch with proof, and report trends honestly, and your patching program will reduce risk instead of merely counting activity.

Frequently Asked Questions

Relevant blogs

Back to all blog guides · Back to Software Development guides · Explore Support and Maintenance Services