New version adoption is one of the most valuable indicators of the quality, reliability, and ease of use of a distributed software package. Replicated recently announced new version adoption reporting. If your software adoption metrics signal challenges with your enterprise customers taking on recent software updates, consider using security as an enabler.
Understanding Enterprise Software Adoption Practices
Enterprise-managed software environments are much more closely controlled than SaaS environments, where customers have little say.
If an enterprise has control over its adoption process, vendors should generally expect it to only take on new software according to specific schedules and after completing scores of requirements and testing. Likewise, an enterprise may only perform updates on predetermined schedules and approved changed windows. For example, did you know that some enterprises go into lockdown around the US Thanksgiving holiday to January? Only emergency changes are permitted during that time because they don't want to risk any problems. After all, it's their most significant revenue time of the year.
Understanding Conflicting Objectives
There are typically three different groups regarding self-managed enterprise software upgrades: Security, Operations, and the Business Owner. Security wants all the upgrades ASAP to address security concerns. Operations are concerned with uptime and may hold up the process to ensure the update doesn't create negative impacts. Finally, the business owner clamors for more upgrades to get new features and wants 100% security and uptime.
That means the vendor will likely have to wait before all the enterprise customers adopt the new software. However, two security-centric strategies can help make the process go faster.
Using SBOM and VEX to Improve Software Adoption
The seemingly obvious security viewpoint to adopt new software versions faster is that more recent software should be less risky. Vendors are keeping up to date with patching, finding, and fixing security vulnerabilities. The truth is that there is only sometimes a direct correlation between new software and fewer security issues. However, there are security-specific guidelines a vendor can utilize to help drive better adoption.
Software Bill of Materials (SBOM)
SBOM is not a new concept, but it has received much attention ignited by software supply chain cybersecurity concerns. The 2019 major cyberattack of SolarWinds, followed by the May 12, 2021, US President Executive Order, made it clear that vendors must start publishing their SBOMs for enterprises to secure their software supply chain better.
Publish SBOMs of your software. A lot of enterprises will want to look at what’s in an update, including changes to 3rd party libraries, open source packages etc. Don’t make the enterprise do that work manually, proactively publish composition of your software and SBOM is a great machine readable way to do so.
Fueled by supply chain concerns, enterprises are more in tune with their vendor's application stacks than ever. That means their security teams will inspect applications by technical and administrative means to investigate all the 3rd party components included in a release. The great news, SBOMs are precisely that. It's a machine-readable way for a vendor to state all the various 3rd party components and their versions included in a release. Vendors can help the enterprise security team by proactively publishing an SBOM with every release.
Vulnerability Exploitability eXchange (VEX)
The Enterprise Security team's job is to ascertain if vendor software is vulnerable to known vulnerabilities or exploits. When a vulnerability is announced, the security team looks at its inventory of software products. They will then need to determine if any software is vulnerable. Part of that process often includes going to vendor websites and contacting vendor support channels. For the vendor, this can be a time-consuming process. However, a relatively new standard called VEX aids both the vendor and the enterprise customer in making this process a lot less time-consuming.
The idea behind VEX is that a vendor publishes a machine-readable file that describes the content of its software and whether or not it is known to be vulnerable to specific security issues. VEX and SBOM work well together but are not mutually exclusive - one does not need SBOM to publish VEX.
In short, VEX contains three parts: Statement, Vulnerability, and Status. The Statement is typically a product or package and its version. Vulnerability is a specific known vulnerability, such as a CVE. Finally, status is an impact statement: Not Affected, Affected, Under Investigation, or Fixed.
If a vendor publishes VEX files for its software, this helps the enterprise quickly identify if its software is vulnerable. More importantly, a vendor can ship a product update with security fixes. As a result, the enterprise security team can quickly identify if it fixes known vulnerabilities. In addition, by doing so, the vendor is giving the security team a more direct reason to lobby its stakeholders to adopt new versions faster.
While VEX is relatively new, we have seen some recent great strides in VEX with the OpenVEX project that makes it much easier to publish and consume VEX files.
Understanding the enterprise software adoption process and objections is crucial for improving your adoption success. Consider using these security tools to help improve your adoption and track your success with Replicated's new Adoption Reporting features.
To learn more, read about our "Secure Everything" use case.