Most successful breaches do not begin with an exotic zero-day. They begin with something far more ordinary, such as a PDF reader three versions out of date, an unpatched browser plugin on a finance laptop, or a Java runtime that nobody realised was still installed on a warehouse terminal. Attackers rarely need to invent a way in when thousands of known, documented and already patched vulnerabilities are sitting unattended across the average corporate estate.
That gap between disclosure and remediation is the reason vulnerability management has moved from a quarterly housekeeping task to a permanent operational discipline. It is also the reason a product called Corporate Software Inspector earned a loyal following among enterprise IT teams, and why administrators still search for it by that name today, years after it was formally renamed.
This guide covers what Corporate Software Inspector is, where it came from, how it works, how it compares with rival tools, and how to implement it well. It is written for the people who run patch cycles, defend audit findings and explain risk to a board.
What Is Corporate Software Inspector?
Corporate Software Inspector, usually shortened to CSI, is an enterprise software vulnerability scanner and third-party patch management solution. It discovers the applications installed across an organisation’s endpoints and servers, checks each one against a curated database of known vulnerabilities, prioritises what matters, then creates and publishes the patches needed to fix them.
The product is now sold and supported by Flexera under the name Software Vulnerability Manager. The underlying purpose has not changed. It exists to close the window between a vulnerability being disclosed and a patch being deployed to every affected machine.
The core purpose in plain English
Two questions sit behind almost every vulnerability management programme:
- What software is actually installed across our estate, including the applications nobody formally approved?
- Which of those installations are vulnerable right now, and how quickly can we fix the ones that matter?
Native Microsoft tooling has historically answered these questions well for Microsoft products and poorly for everything else. Corporate Software Inspector was built to cover the rest, which is where the majority of an enterprise’s third-party risk usually sits.
Adobe, Oracle Java, Google Chrome, Mozilla Firefox, Zoom, 7-Zip, Notepad++, VLC, PuTTY, Citrix Workspace, TeamViewer and hundreds of similar applications all ship their own update mechanisms, on their own schedules, in their own installer formats.
A short history: from Secunia to Flexera
Corporate Software Inspector began life at Secunia, a Danish security research company founded in Copenhagen in 2002. Secunia built its reputation on vulnerability intelligence. Its researchers verified vendor claims and published advisories that mapped vulnerabilities to specific product versions.
The first version of Corporate Software Inspector launched in 2008 as a scanning engine that determined the patch status of applications on corporate systems. Over time it evolved well beyond assessment.
Integration with Microsoft WSUS and System Center Configuration Manager meant that customers could not only detect a vulnerable application, but also package and deploy the fix from the same workflow. For many organisations, CSI became shorthand for complete third-party patch management.
Flexera acquired Secunia on 15 September 2015. The rationale was the overlap between software asset management and security. Flexera already had deep visibility into what software enterprises owned and used through its licensing and asset products. Secunia knew which of that software was vulnerable. Combining the two made commercial and technical sense.
Why it is now called Software Vulnerability Manager
In 2018, Flexera renamed the product. The change took effect with the release scheduled for the first half of May that year. Flexera’s own explanation was straightforward: the product no longer simply inspected software. It managed the full vulnerability lifecycle, from detection through prioritisation to patch creation, deployment and reporting. The word “inspector” described the 2008 product, not the 2018 one.
The functionality and interface carried over. Customers were not migrated to a different platform. The name on the console changed, the licence agreements changed, and the product roadmap continued in the same direction.
Why organisations still search for Corporate Software Inspector
Product names change far faster than institutional memory. Several practical reasons keep the original term alive:
- Long deployment lifespans. Enterprise patch tooling often stays in place for a decade or more. Teams that deployed CSI in 2012 still refer to it that way internally.
- Documentation and runbooks. Internal wikis, change management templates and standard operating procedures written years ago still say CSI.
- Flexera’s own artefacts. Product documentation paths and release note filenames still carry the legacy identifier, so search engines continue to surface the old name.
- Procurement records. Purchase orders, renewals and asset registers frequently list the original product name.
- Community habit. Forum threads, Reddit posts and vendor comparison articles written before 2018 remain heavily indexed.
If you are researching Corporate Software Inspector today with a view to buying, evaluating or renewing, you are researching Flexera Software Vulnerability Manager. The rest of this guide treats them as the same product, because functionally they are.
Why Businesses Need Corporate Software Inspector
The case for a dedicated software vulnerability scanner rests on a set of problems that most IT teams recognise immediately.
Outdated third-party software
Operating system patching is a solved problem in most enterprises. Windows Update, WSUS, Configuration Manager and Intune handle it on a predictable monthly rhythm. Third-party applications are the weak point. They update through per-application auto-updaters that standard users often cannot trigger, or that corporate policy has deliberately disabled to prevent uncontrolled change.
The result is a long tail of installations sitting several versions behind, each carrying every vulnerability fixed since the version in use was released.
Missing patches for known vulnerabilities
The uncomfortable truth of most incident post-mortems is that a fix existed. CISA maintains a Known Exploited Vulnerabilities catalogue precisely because attackers concentrate their effort on a relatively small set of flaws that are confirmed to work in the wild. Those entries are, overwhelmingly, vulnerabilities with available patches.
A vulnerability assessment tool that tells you which of those specific issues exist in your environment, and hands you the patch, closes the gap that generic scanning leaves open.
Zero-day and newly disclosed vulnerabilities
Genuine zero-days are rare. What is common is the period immediately after a disclosure, when exploit code circulates and the vulnerability is public but the estate is not yet patched. This is the window that matters operationally.
Speed here depends on three things: knowing within hours whether you are affected, knowing how many machines are affected, and having a packaged patch ready to publish. A mature CVE management process compresses that from weeks to days.
Shadow IT and unmanaged installations
Every organisation has software it did not plan for. Developers install utilities. Marketing teams install design tools. Contractors bring their own preferences. Portable applications that run without installation are especially awkward, because they may never appear in a licensing system or a formal enterprise software inventory.
An authenticated scan that inspects the file system rather than just querying installed program lists surfaces these installations, which is often the first time anyone sees the true shape of the estate.
Compliance and regulatory pressure
Vulnerability and patch management appear as explicit requirements in almost every framework that enterprises are measured against, including ISO/IEC 27001, PCI DSS, Cyber Essentials in the UK, HIPAA security requirements in healthcare, and the NIST Cybersecurity Framework. Newer regimes such as NIS2 and DORA in the European Union have raised the expectations for demonstrable process rather than best effort.
Auditors rarely accept “we patch regularly” as evidence. They want records showing what was found, how it was prioritised, when it was fixed and what remains open with a documented reason.
Ransomware and initial access
Ransomware operators and the access brokers who supply them favour reliable, well-documented entry points. Unpatched remote access tools, file transfer utilities, VPN clients and browsers are perennial favourites. Reducing the number of exposed, exploitable applications reduces the number of ways in, which is unglamorous but effective endpoint security.
How Corporate Software Inspector Works
The workflow is best understood as a loop rather than a linear process. Each stage feeds the next, and the cycle repeats on a schedule.
1. Software discovery
An agent installed on each endpoint, or a scan run against the device, inspects what is present. The scan does not rely solely on registry entries or the Programs and Features list. It examines executable and library files to identify applications and their exact versions, which is how portable and non-standard installations get detected.
Scanning covers Windows, macOS and Red Hat Enterprise Linux systems, which reflects where most corporate desktop and server estates sit.
2. Inventory and normalisation
Raw scan data is messy. The same application can report itself half a dozen different ways depending on installer, locale and version. The platform normalises this into a clean enterprise software inventory: one product, one recognised version, one count of installations.
This inventory has value beyond security. It is frequently the first accurate picture an organisation has had of what is genuinely deployed, which feeds directly into IT asset management and licence reconciliation.
3. Vulnerability detection
Each identified product version is matched against vulnerability intelligence. Flexera’s Secunia Research team has produced security advisories since 2002, and those advisories are the backbone of detection. An advisory consolidates the relevant CVE records, states which versions are affected, describes the attack vector, and confirms whether a fix exists.
The distinction between an advisory and a raw CVE feed matters in practice. A single vendor update often resolves a dozen CVEs. An advisory presents that as one actionable item rather than twelve alerts pointing at the same fix. This is also why many organisations value a curated source alongside public data, particularly given the well-documented slowdown in enrichment of records in the NIST National Vulnerability Database from early 2024, which left many CVE entries without the metadata that automated tooling depends on.
4. Risk prioritisation
A scan across a mid-sized estate can return thousands of findings. Prioritisation determines what actually gets done.
Severity ratings and CVSS scores form the baseline. Threat intelligence adds the more useful dimension: whether a vulnerability is being exploited in the wild, whether exploit code is publicly available, and whether it is being discussed on criminal forums. Flexera offers this as a Threat Intelligence Module that scores vulnerabilities using a mix of machine learning and human curation drawn from open, deep and dark web sources.
The practical output is a shortlist. A critical vulnerability with active exploitation on 900 endpoints outranks a medium-severity issue on three machines in a lab, regardless of what the raw CVSS numbers suggest.
5. Patch creation and packaging
This is where the product differs from a scanner that stops at reporting. Two mechanisms handle remediation:
- The Flexera Package System (SPS) builds patch packages for third-party applications, including the ability to customise installation behaviour, suppress shortcuts, disable auto-updaters and apply silent installation switches.
- The Vendor Patch Module (VPM) provides a large library of pre-packaged, ready-to-deploy third-party patches, which removes most of the manual packaging work for common applications.
Once a package is configured for an application, subsequent versions of that application can be prepared automatically using the same configuration.
6. Publishing and deployment
The platform does not usually replace your existing deployment infrastructure. It feeds it. The SVM Patch Publisher, which succeeded the older Patch Daemon, connects the vulnerability platform to your endpoint management system and publishes packages into it.
Supported targets include Microsoft WSUS and System Center Configuration Manager, Microsoft Intune, VMware Workspace ONE, BigFix and Tanium. Deployment then follows your existing change control: maintenance windows, pilot rings, user notifications and rollback plans all stay under the control of the tool your operations team already uses.
7. Verification and reporting
The next scan cycle confirms whether the patch actually landed. Reporting turns that into evidence: current risk posture, remediation trends over time, outstanding critical items, and compliance status against internal policy.
A worked example
Consider a manufacturer with 4,000 endpoints across five sites.
- A scheduled scan identifies 312 installations of a widely used archiving utility, spread across eleven different versions.
- The platform flags that 240 of those installations are affected by a vulnerability that allows arbitrary code execution when a crafted archive is opened. Threat intelligence indicates active exploitation.
- The finding rises to the top of the prioritised list. The team sees exactly which 240 machines are affected, and which departments they belong to.
- A patch package is pulled from the Vendor Patch Module, configured to install silently and to remove the older version.
- The package is published to Configuration Manager, deployed to a pilot group of 30 machines overnight, then to the remaining 210 across the next two maintenance windows.
- The following scan confirms zero remaining vulnerable installations, and the report is filed as evidence for the quarterly security review.
Without tooling of this kind, step two alone typically consumes days of manual effort and produces an incomplete answer.
Key Features
The following capabilities define what Corporate Software Inspector, now Software Vulnerability Manager, actually delivers.
Automated software inventory
Continuous, agent-based discovery of installed applications across Windows, macOS and Red Hat Enterprise Linux, with version-level accuracy. Because detection is based on file inspection rather than registry entries alone, it finds installations that conventional inventory tools miss.
Vulnerability scanning and assessment
Authenticated internal scanning that assesses the patch state of installed software rather than probing for exposed network services. This is a fundamentally different technique from network vulnerability scanning, and it is considerably more accurate for desktop and application-layer risk.
Third-party patch management
The strongest single reason organisations buy the product. Thousands of third-party applications are supported with pre-built or configurable patch packages, covering the applications that Microsoft’s native tooling does not address.
Secunia Research security intelligence
Human-verified advisories rather than automated CVE aggregation. Advisories confirm affected versions, describe impact and attack vector, and state solution status. This reduces both false positives and the noise of duplicate findings.
Dashboards and visualisation
Role-appropriate views: an operational queue for the team doing the patching, and trend-based summaries for the security manager or CIO who needs to see whether risk is going up or down.
Compliance reporting
Scheduled and custom reports covering vulnerability status, remediation progress and policy compliance. These serve internal governance as well as external audit, and they are frequently the reason a security team can demonstrate control rather than assert it.
Patch deployment integration
Publishing into WSUS, System Center Configuration Manager, Intune, Workspace ONE, BigFix and Tanium. Patches arrive in the console your operations team already uses, which removes a major source of organisational friction.
Risk scoring and threat intelligence
Prioritisation that goes beyond severity ratings by incorporating evidence of real-world exploitation. This is the difference between a list of 3,000 findings and a list of the 40 that need attention this week.
Microsoft ecosystem integration
Deep integration with the Microsoft patching stack has been a defining characteristic since the WSUS and System Center era, and it now extends to Intune for organisations that have moved to cloud-managed endpoints.
Automation
Patch automation rules allow defined categories of update, for example browser updates rated critical, to be packaged and published without manual intervention, while higher-risk applications remain under manual review.
| Feature | What it does | Who benefits most |
|---|---|---|
| Automated software inventory | Builds an accurate, version-level record of installed applications | Software asset managers, IT operations |
| Vulnerability scanning | Identifies vulnerable versions using authenticated local assessment | Security teams |
| Third-party patch management | Creates and publishes patches for non-Microsoft software | Desktop and endpoint teams |
| Secunia Research advisories | Supplies verified vulnerability intelligence | Security analysts |
| Threat intelligence scoring | Highlights vulnerabilities under active exploitation | SecOps, risk managers |
| Compliance reporting | Produces evidence of patching activity and posture | CISOs, auditors, compliance officers |
| Deployment integration | Publishes patches into existing management systems | IT operations, MSPs |
| Patch automation | Removes repetitive packaging work for routine updates | Lean IT teams |
Benefits for Enterprise IT
Reduced cyber risk
The measurable outcome is a smaller attack surface. Fewer vulnerable applications, patched faster, means fewer viable routes for an attacker who is scanning for known weaknesses rather than developing novel ones.
Faster patching cycles
Mean time to remediate is the metric that matters, and packaging is usually the bottleneck. Pre-built third-party packages and automation rules remove most of that delay. Teams that previously took weeks to roll out a browser update can often do it within days.
Improved compliance posture
Consistent, exportable evidence turns audit preparation from a scramble into a routine export. It also supports internal service level agreements, for example a policy stating that critical vulnerabilities are remediated within fourteen days.
Less manual work
Manually repackaging the same handful of applications every month is a poor use of skilled staff. Automating that work frees engineers for architecture, hardening and incident response.
Better visibility
Many organisations discover during initial deployment that their estate contains software nobody knew about, including unlicensed installations and applications from vendors that no longer exist. That visibility has value well beyond security.
Centralised management
Assessment, prioritisation, packaging and publishing in one console reduces handoffs between the security team that identifies a problem and the operations team that fixes it. Those handoffs are where remediation usually stalls.
Cost efficiency
Savings come from three directions: reduced labour on manual packaging, reduced likelihood and cost of incidents, and better licence decisions informed by accurate inventory data. The last of these is often overlooked and frequently significant.
Common Use Cases
Banking and financial services
Regulated environments with strict change control and low tolerance for unplanned downtime. The appeal here is the combination of prioritisation, so that only justified changes are pushed, and detailed evidence trails for regulators. Trading floors and branch estates both benefit from tightly controlled third-party patching.
Healthcare
Hospitals run an unusually diverse mix of clinical applications, imaging software, administrative systems and legacy platforms tied to medical devices. Not everything can be patched immediately. Accurate inventory and risk scoring let teams identify what must be patched, what must be compensated for with network segmentation, and what genuinely cannot be touched.
Government and public sector
Large, distributed estates with formal security baselines and standing reporting obligations. Central IT functions often need to demonstrate patch compliance across multiple departments or agencies operating semi-independently.
Education
Universities combine centrally managed staff devices with research computing, labs and departmental autonomy. Software diversity is extreme, and discovery is frequently the primary value, because knowing what is installed across a faculty estate is an achievement in itself.
Manufacturing
Plant environments have limited maintenance windows and a strong operational bias against unplanned change. Prioritisation is essential, because patching everything is not an option when production lines depend on stability. Engineering workstations running CAD and vendor-specific tooling are typical high-risk targets.
Retail
Distributed store estates with point of sale systems, back office machines and thin support locally. PCI DSS obligations make documented patch management a contractual necessity, and centralised packaging matters enormously when there is no local technician.
SaaS and technology companies
Developer machines carry a wide range of tools, runtimes, libraries and utilities, much of it installed without central approval. Discovery and risk-based prioritisation help security teams manage this without imposing controls that would slow engineering down.
Managed IT service providers
MSPs need repeatable processes across many client environments, along with reporting they can show clients each month. Standardised packaging and multi-tenant reporting make third-party patch management a deliverable service rather than an unbounded cost.
Corporate Software Inspector vs Software Vulnerability Manager
This is the single most common point of confusion, so it is worth stating plainly. They are the same product. Corporate Software Inspector is the former name, Software Vulnerability Manager is the current one.
| Aspect | Corporate Software Inspector | Software Vulnerability Manager |
|---|---|---|
| Original developer | Secunia, Copenhagen | Same lineage, now Flexera |
| Launched | 2008 | Renamed in 2018 |
| Ownership | Secunia, then Flexera from September 2015 | Flexera |
| Core purpose | Assessment and third-party patching | Full vulnerability lifecycle management |
| Intelligence source | Secunia Research | Secunia Research |
| Deployment integration | WSUS, System Center Configuration Manager | WSUS, Configuration Manager, Intune, Workspace ONE, BigFix, Tanium |
| Editions | On-premises | Cloud and on-premises |
The differences in that table are the product of a decade of development, not of a different product. Anyone still running an older CSI deployment is running an ancestor of what is sold today, and the upgrade path stays within the same product family.
One related clarification: Secunia also published a free consumer tool called Personal Software Inspector, or PSI, which scanned home PCs for outdated applications. That product was retired some years ago and was never the enterprise offering, despite the similar name.
Corporate Software Inspector vs Other Solutions
No single tool wins on every axis. The right choice depends on whether your primary problem is third-party patching, broad infrastructure scanning, endpoint management consolidation or exposure analytics.
| Solution | Deployment | Vulnerability scanning | Patch management | Reporting | Automation | Best suited to |
|---|---|---|---|---|---|---|
| Flexera Software Vulnerability Manager (Corporate Software Inspector) | Cloud or on-premises, agent based | Authenticated software assessment, strongest on third-party applications | Native packaging and publishing for third-party software | Detailed compliance and remediation reporting | Patch automation rules and reusable package configurations | Enterprises whose main gap is third-party patching alongside Microsoft tooling |
| Microsoft Intune | Cloud, Microsoft ecosystem | Limited natively, relies on Defender Vulnerability Management | Strong for Microsoft, limited for third party without add-ons | Device and configuration focused | Strong policy automation | Microsoft-centric estates already committed to cloud endpoint management |
| ManageEngine Patch Manager Plus | Cloud or on-premises | Patch-state focused rather than full assessment | Broad third-party catalogue, straightforward to run | Practical operational reporting | Good scheduling and approval automation | Mid-market organisations wanting cost-effective patching |
| Qualys VMDR | Cloud, agent and scanner | Very broad, covering network, cloud and endpoints | Patch capability available as part of the platform | Extensive analytics and dashboards | Workflow automation across the platform | Large enterprises wanting one platform across all asset types |
| Rapid7 InsightVM | Cloud with on-premises components | Broad infrastructure and application scanning | Orchestrated through integrations rather than native packaging | Strong risk analytics and remediation projects | Automation through connected workflows | Security-led teams focused on risk analytics |
| Tenable Nessus | On-premises scanner, wider platform available | Industry standard for breadth of vulnerability checks | No native patch deployment | Comprehensive technical scan reporting | Scan scheduling, limited remediation automation | Assessment, audit and penetration testing workflows |
| Ivanti Neurons | Cloud and on-premises | Risk-based vulnerability assessment | Strong patch management including third party | Unified IT and security reporting | Extensive automation and self-healing features | Organisations consolidating endpoint management and security |
| CrowdStrike Falcon Exposure Management | Cloud, single agent | Continuous, agent-based exposure assessment | No native third-party patch packaging | Strong exposure and threat context | Automation tied to the wider Falcon platform | Existing CrowdStrike customers wanting exposure visibility |
How to read that comparison
A few practical distinctions matter more than feature counts.
- Scanning breadth versus remediation depth. Tenable, Qualys and Rapid7 assess more asset types, including network devices, cloud workloads and web applications. Flexera’s product goes deeper on one specific problem, which is patching third-party software on managed endpoints. Many large organisations run both, and that is a legitimate architecture rather than duplication.
- Native packaging is rare. Most vulnerability scanners tell you what to fix. Comparatively few build the patch package and publish it to your deployment system. That capability is the historical core of Corporate Software Inspector.
- Platform consolidation has a pull of its own. If you are already deeply invested in Intune, CrowdStrike or Ivanti, one fewer console carries real weight, even where a specialist tool is technically stronger.
- Endpoint coverage differs. Confirm current platform support against your estate before shortlisting, particularly with significant macOS or Linux populations.
Best Practices for Implementation
Tooling only produces results when the surrounding process is sound. The following practices reflect what tends to separate effective programmes from expensive shelfware.
Start with accurate discovery
Deploy agents broadly before attempting to fix anything. An incomplete inventory produces misleading metrics and false confidence. Aim for near-complete coverage of managed endpoints and servers first, then start remediating.
Define risk-based policies, not blanket rules
A policy that says “patch everything within 30 days” fails on contact with reality. A tiered policy works better:
- Critical vulnerabilities with confirmed active exploitation: emergency change, target within 72 hours.
- Critical and high severity with available patches: within 14 days.
- Medium severity: within the standard monthly cycle.
- Low severity: bundled into scheduled application refreshes.
Use deployment rings
Pilot on IT staff machines, then a representative cross-section of business users, then the wider estate. Third-party patches occasionally break workflows, and finding that out on 30 machines is considerably better than finding out on 3,000.
Automate the routine, review the sensitive
Browsers, media players, archiving tools and similar low-risk applications are good candidates for full automation. Applications embedded in business processes, such as CAD software, clinical systems or line-of-business integrations, should stay under manual review.
Align security and operations from the outset
The most common failure mode is organisational rather than technical. Security identifies vulnerabilities, operations owns the deployment infrastructure, and neither owns the outcome. Agree jointly on service levels, escalation paths and who authorises emergency patching before the first crisis.
Measure the right things
Track mean time to remediate, patch coverage as a percentage of affected endpoints, the volume of open critical findings over time, and the age of the oldest unresolved critical vulnerability. Raw finding counts are a poor measure of progress because they fluctuate with disclosure volume.
Document exceptions properly
Some systems genuinely cannot be patched. Record the reason, the compensating control, the review date and the approving owner. An undocumented exception is a finding waiting to happen. A documented one is a managed risk.
| Practice | Why it matters | Common failure if skipped |
|---|---|---|
| Complete discovery first | Metrics are only meaningful with full coverage | Blind spots in unmanaged or remote devices |
| Tiered remediation SLAs | Focuses effort on genuine risk | Teams overwhelmed and nothing gets fixed |
| Pilot rings | Contains the impact of a bad patch | Estate-wide outages and loss of confidence |
| Selective automation | Removes repetitive work safely | Either no automation or reckless automation |
| Joint security and operations ownership | Prevents findings stalling between teams | Long-lived critical vulnerabilities |
| Exception register | Turns unpatchable systems into managed risk | Repeat audit findings |
Common Mistakes and How to Avoid Them
Treating the tool as the strategy
Buying a software vulnerability scanner does not create a vulnerability management programme. Ownership, service levels, escalation routes and reporting cadence do. Decide those before deployment, not after the first quarterly review goes badly.
Chasing every finding
Teams that attempt to drive the finding count to zero exhaust themselves and still miss the important items. Prioritisation is not a compromise, it is the entire point. Fix what is exploitable and exposed first.
Ignoring servers or, conversely, ignoring endpoints
Server teams sometimes assume endpoints are low value. Desktop teams sometimes assume servers are someone else’s problem. Attackers move between the two. Coverage should follow the risk, not the org chart.
Disabling auto-updaters without replacing them
Corporate policy frequently disables application auto-updates to maintain change control, which is reasonable. The failure comes when nothing replaces them. If you turn off a vendor’s update mechanism, you own that application’s patching from that point onwards.
Deploying agents to only part of the estate
Coverage gaps distort everything. Remote workers, contractor devices, machines that rarely connect to the corporate network and long-forgotten test servers are the usual offenders. Reconcile agent coverage against your directory and asset records regularly.
Under-resourcing packaging and testing
Pre-built patches reduce effort substantially but do not eliminate it. Applications with unusual configurations still need testing. Allocate time for this, rather than assuming automation removes the work entirely.
Producing reports nobody reads
A 90-page technical report sent monthly to an executive audience achieves nothing. Produce two outputs: an operational queue for the people doing the work, and a short trend summary showing whether risk is rising or falling for everyone else.
Neglecting decommissioning
Some findings are best resolved by removing the software entirely. If an application is unsupported, rarely used or duplicated by something already deployed, uninstalling it is faster, cheaper and permanent. Good inventory data makes these opportunities visible.
Frequently Asked Questions
Is Corporate Software Inspector still available?
Yes, under its current name. Flexera sells and supports it as Software Vulnerability Manager, available in cloud and on-premises editions. The Corporate Software Inspector name was retired in 2018.
Who originally developed Corporate Software Inspector?
Secunia, a security research company founded in Copenhagen in 2002. The first version of the product launched in 2008. Flexera acquired Secunia on 15 September 2015.
Why was it renamed to Software Vulnerability Manager?
Because the product had outgrown its name. It no longer just inspected software, it managed detection, prioritisation, patch creation, deployment and reporting. Flexera made the change effective with the release in the first half of May 2018.
What operating systems does it support?
Assessment and patching cover Microsoft Windows, macOS and Red Hat Enterprise Linux systems. Confirm the exact supported versions against current Flexera documentation before purchase, since support matrices change with each release.
Does it replace Microsoft SCCM or Intune?
No, it complements them. It identifies vulnerable third-party software, packages the fix, then publishes it into WSUS, Configuration Manager, Intune or another supported system. Your existing deployment infrastructure remains the delivery mechanism.
How is it different from a network vulnerability scanner?
A network scanner probes systems from the outside, testing exposed services and inferring risk. Corporate Software Inspector performs authenticated assessment from inside the endpoint, checking installed software versions against known vulnerabilities. It is more accurate for application-layer risk and it can remediate what it finds.
What is Secunia Research and why does it matter?
It is Flexera’s in-house vulnerability research team, which has published security advisories since 2002. Advisories are verified by researchers rather than aggregated automatically, which reduces false positives and consolidates multiple related CVEs into one actionable item.
Does it detect zero-day vulnerabilities?
No tool reliably detects vulnerabilities that are unknown and undisclosed. What it does is shorten the time between disclosure and remediation, which is where most real-world risk actually sits. It also flags where a vulnerability exists in your environment before an official patch is available, so compensating controls can be applied.
Can it help with software licensing and asset management?
Indirectly, and usefully. The inventory it builds is often the most accurate record an organisation has of installed applications, which supports licence reconciliation and rationalisation. Flexera’s dedicated IT asset management products go considerably further.
How long does implementation take?
Initial deployment and first scans are typically measured in weeks rather than months for a mid-sized estate. Reaching a mature, automated patching cycle usually takes a quarter or two, largely because of process design, agent coverage and testing rather than technical installation.
Is it suitable for small businesses?
It is designed for enterprise-scale estates, and both licensing and operational overhead reflect that. Smaller organisations often find better value in lighter patch management software or in the third-party patching capabilities bundled with their existing endpoint management platform.
Does it support compliance frameworks?
It supports the evidence requirements of frameworks such as ISO/IEC 27001, PCI DSS, Cyber Essentials and the NIST Cybersecurity Framework by documenting what was found, how it was prioritised and when it was fixed. No tool delivers compliance on its own, but reporting of this kind is usually what auditors ask for.
What is the Vendor Patch Module?
An add-on providing a large library of pre-packaged third-party patches, which removes most of the manual work of building packages for common applications. It sits alongside the Flexera Package System, which is used where custom packaging is required.
How does it prioritise which vulnerabilities to fix first?
Through a combination of advisory severity, CVSS data, the number of affected installations, and threat intelligence about active exploitation. Flexera’s Threat Intelligence Module adds scoring drawn from machine learning and human curation across open, deep and dark web sources.
Can managed service providers use it for multiple clients?
Yes. MSPs commonly use it to deliver standardised third-party patch management across client estates, with reporting they can share with each client. Licensing arrangements for multi-tenant use should be confirmed with Flexera or an authorised partner.
Conclusion
Corporate Software Inspector solved a problem that has not gone away. Enterprises run hundreds of third-party applications that update on their own schedules, in their own formats, outside the reach of native operating system patching. Left alone, those applications accumulate known, documented and entirely fixable vulnerabilities that attackers actively hunt for.
The product now called Flexera Software Vulnerability Manager addresses that by combining four things that rarely appear together: accurate software discovery, verified vulnerability intelligence from Secunia Research, risk-based prioritisation, and the ability to package and publish patches into the deployment tools an organisation already runs.
Three points are worth carrying away. First, the name change from Corporate Software Inspector to Software Vulnerability Manager was a rebrand, not a replacement, so research conducted under either name applies to the same product.
Second, the product’s distinctive strength is third-party patch management rather than breadth of scanning, which means it often sits alongside a broader vulnerability assessment platform rather than replacing one.
Third, and most importantly, the tool is only half the answer. Clear ownership between security and operations, tiered remediation targets, sensible automation and honest exception handling are what turn a scanner into a functioning vulnerability management programme.
Organisations that get those fundamentals right tend to find the next major disclosure is routine work rather than a crisis. That, more than any feature list, is the outcome worth aiming for.
Published By ITInfosys UK.
