In simple terms we think of a Software Bill of Materials (SBOM) as an inventory of the software components found in software applications—open source, third-party, and custom code. It may be that not all developers, security personnel, and stakeholders truly recognize the impact third-party libraries have, however, on the software supply chain. Having said that and given the supply chain has gotten way more complex in the recent years, that simple definition of an SBOM no longer encapsulates everything it should represent and accomplish, from improved efficiencies and cost reduction to addressing technical debt.

While things are speeding along (a lot has happened over the last few years, specifically) most organizations are still trying to figure out why they’re needed, who needs them, what should be included in an SBOM and once we have them what the heck do we do with them? In the not knowing or understanding how critical an SBOM is to identifying and avoiding software vulnerabilities, perhaps you’re thinking, “We’re good.”

Given that, the obvious question is how comprehensive are your efforts and what’s the plan to implement a more effective approach? Secondly, is there a tool you can use to assess your SBOM management readiness?

SBOM Maturity Framework

Revenera has devised a framework made up of three specific levels of maturity for SBOM management. This framework applies to all companies serving various industries:

1. Reactive – You have some general awareness of what’s happening with emerging security regulations, but SBOM management has yet to take on a strategic focus and most likely requires manual construction.
2. Enabled – SBOM Management has taken a strategic focus, but you might still be deciding where it rests in the organization. SBOM transparency is a high priority, and you continuously work to approach it in a way that meets not just the needs of your business.
3. Optimized – Your organization has assigned responsibility for supply chain security and SBOMs are part of your business strategy for security and compliance risk mitigation. You have an automated and scalable SDLC process in place that is tied to your DevSecOps pipelines for SBOM construction, refinement, and utilization.

This model assesses business processes and technological functionality in four key dimensions of SBOM management.

Strategic Focus

This element of readiness looks at the extent SBOMs are woven into the fabric of an overarching compliance and security strategy. Is there a formalized team such as an OSPO dedicated to SBOM management? Have clearly defined metrics been identified to measure both success and progress? With an optimized strategy, an organization has operationalized SBOM generation, refinement, and delivery. 

SBOM Construction

With an enhanced approach to SBOM construction, SBOM functionality is integrated with software development and tracks all software components, regardless of where they originated and includes commercial, third-party, and proprietary components along with all direct and transitive dependencies.

Data Sharing

The process of sharing SBOM data is crucial to a highly optimized SBOM management program because it gives data access to the right people at the right time. Sharing data across the software supply chain involves having the right technical platform, data formats, and operational processes in place throughout the software supply chain for greater collaboration.

Automation Integration/Continuous Process 

This element of SBOM maturity looks at whether SBOM construction is both automated and continuous so there is a complete picture of legal and security risks in real time. Manual analysis, curation, and processing SBOM data is time consuming, especially since the smallest software applications can still be composed of many components. Automation ensures continuous scanning to produce SBOMs, creates consistency, and promotes increased transparency.

Assess Your SBOM Readiness

As I mentioned above, hype around SBOMs has taken off over the last several years, largely due to regulatory bodies stepping in to improve efforts to secure the software supply chain and protecting organizations against malicious actors. Along with all the hype comes confusion.

The goal is to embrace an SBOM approach that helps you build a robust security posture through automation and fast identification and mitigation of risk. SBOMs should provide a 360-degree view of your risk exposure up and down the software supply chain.

To help, Revenera created the SBOM Maturity Assessment. We encourage you to take a few minutes to answer some questions about your processes. In return, we’ll provide you with an evaluation of your SBOM management practices along with actionable next steps to controlling open source, third-party, and commercial component use through the strategic implementation of an SBOM.

Impact to Open Source Use

In March 2023, the U.S. Government released the National Cybersecurity Strategy. Recently, the White House followed up by releasing its implementation plan to support that strategy—the National Cybersecurity Strategy Implementation Plan (NCSIP). The plan is intended to be a roadmap to accomplish the goals set out by the administration when it announced the Cybersecurity Executive Order (EO) in 2021. You could say this plan is long awaited by many organizations that want to better understand how the U.S. government is going to proceed, how fast they plan on getting it done, and, more importantly, what’s expected of organizations to meet requirements.

For organizations building applications with open source—and let’s face it, open source is in almost everything—and for those companies selling software to the U.S. government, there are some key takeaways in this plan.

The Software Bill of Materials (SBOM)

We wrote a lot initially about what was in the Cybersecurity EO about SBOMs. The order explicitly laid out the idea that in order to protect our nation from “malicious cyber actors” the Federal Government and private sector must work together to enhance the software supply chain. Specific requirements in the order included:

• Providing a purchaser a SBOM for each product either directly or by other means such as a website
• Employing automated tools or processes to maintain trusted source code supply chains and ensuring code integrity

In this new plan, CISA owns the responsibility to work across the government to reduce gaps in SBOM implementation, establish requirements for an end-of-life database and to level-up international communication and coordination efforts by establishing an SBOM team:

“In order to collect data on the usage of unsupported software in critical infrastructure, the Cybersecurity and Infrastructure Agency will work with key stakeholders, including SRMAs [Sector Risk Management Agencies], to identify and reduce gaps in SBOM scale and implementation. CISA will also explore requirements for a globally-accessible database for end-of-life/end-of-support and convene an international staff level working group on SBOM.”

Leverage Federal Procurement to Improve Accountability

In Section 3.5 of the implementation plan, the Office of Management and Budget and the Federal Acquisition Regulatory Counsel are tasked with making changes to the Federal Acquisition Regulation to add mandatory requirements to government contracts around cybersecurity incident reporting and secure software requirements. This will most likely standardize those requirements for all government agencies and anyone selling into the government.

Open Source Software Security Initiative

The plan provides the ability for the Office of the National Cyber Director (ONCD) and the Cybersecurity and Infrastructure Security Agency (CISA) to establish a new initiative it has dubbed OS3I—Open Source Software Security Initiative—to improve the baseline security level of open source software. The purpose of OS3I is to engage public and private stakeholders to learn about risks and opportunities to improve the security of the open-source software ecosystem.

“The Office of the National Cyber Director will establish an Open-Source Software Security Initiative (OS3I) to champion the adoption of memory safe programming languages and open-source software security. As part of this initiative, CISA will work with the OS3I and the open-source software community to enable the secure usage of open-source software in the Federal Government and critical infrastructure, and to raise the security baseline of the open-source software ecosystem. CISA will also develop close partnerships with open-source software community members and integrate into various community efforts.”

More details as to how they are going to accomplish the above are coming. The current deadline to establish the plan is Q1 of 2024.

Utilize the False Claims Act to Improve Vendor Cybersecurity

The question becomes, how is the government going to hold organizations accountable for cybersecurity failures? Section 3.5 of the plan begins to answer that question. The National Cybersecurity Strategy released earlier this year also began to lay the groundwork:

“The Civil Cyber-Fraud Initiative (CCFI) uses DOJ authorities under the False Claims Act to pursue civil actions against government grantees and contractors who fail to meet cybersecurity obligations. The CCFI will hold accountable entities or individuals that put U.S. information or systems at risk by knowingly providing deficient cybersecurity products or services, knowingly misrepresenting their cybersecurity practices or protocols, or knowingly violating obligations to monitor and report cyber incidents and breaches.”

The Department of Justice owns the process for creating a framework for investigating false claims around cybersecurity. Included in its directive is how to penalize vendors for violating and/or misrepresenting cybersecurity protocols.

Secure by Design

According to the plan, CISA will lead public/private partnerships with technology manufacturers, educators, non-profit organizations, academia, the open source community, and others to drive the development and adoption of software and hardware that is secure by design and secure by default. It goes further by stating that, “CISA will identify barriers to adoption for such principles and best practices, and will work to drive collective action to adopt these principles across the private sector.”

Regardless of where you sit in the world of open source—user or creator; developer or advocate—I believe one of the most important elements of helping projects and people thrive is active engagement with the open source community. It’s about raising awareness and standing up for the benefits of open source in order to collaborate and grow. The U.S. Federal Government understands that it needs this community to help bridge the gaps in its cybersecurity defense plans and create cohesive policy.

Cyber Trust Mark

In a more recent development as part of an ongoing focus on cybersecurity, the Biden administration launched a new cybersecurity label for smart devices.

In a press briefing, Federal Communications Commission (FCC) Chair Jessica Rosenworcel said the new label, called the U.S. Cyber Trust Mark, will signify that devices bearing it meet security standards based on those established in a report by the National Institute of Standards and Technology (NIST). The voluntary program is expected to be in place in 2024, with the labels hitting devices “soon after.”

We will continue to provide updates and key deadlines as they become available.

As technology companies evolve, various types of software licensing models are introduced to the market – giving both buyers and suppliers more control over how products and services are sold and consumed.

Ultimately, a software licensing model allows publishers to define the parameters for access, usage, and pricing, enabling you to implement diverse product monetization strategies that protect IP and cater to market demands.

If you’re in the process of evaluating the best approach for your organization, this guide provides an overview of the most popular licensing models for software, all of which can be facilitated via Revenera’s flexible, award-winning software licensing solutions.

For a broader definition, you may be interested in: What is Software Licensing?

Popular Types of Software Licensing Models

Subscription/Term Licensing

As the name suggests, a subscription licensing model allows customers to pay a recurring fee to access a product or service for a fixed term, i.e., on a monthly or annual basis. This approach has been widely adopted for platforms such as Microsoft 365 and the Adobe Creative Cloud, and customers frequently enjoy the benefits of regular updates, patches, and ongoing support while they remain a subscriber.

Revenera’s Monetization Monitor has charted the rise of subscription/term licensing for several years, and it consistently ranks as the highest area of expected growth for overall software license revenue. In the most recent report, 54% of respondents indicated this was their primary focus for greater adoption, putting it above all other types of software licensing models.

Consumption/Usage-Based Licensing

Consumption licensing is an approach centered on a commitment to consume a certain amount of usage – whether based on time, frequency of use, storage volumes, or product-specific metrics related to particular features or actions. Typically, credit is purchased in advance, and units are subsequently deducted with each use.

Pay-Per-Use Licensing

As the name suggests, pay-per-use allows suppliers to define unit costs and usage metrics, and charge users accordingly.

Pay-for-Overage Licensing

Another form of usage-based pricing whereby, instead of restricting use once a threshold has been met, you allow consumption above the pre-defined limit and bills are paid accordingly.

Device Licensing

Hardware manufacturers are increasingly turning to software-first business models in attempts to generate recurring revenue, so device licensing has become a prominent form of IoT monetization.

Applying to a certain number of devices, software is installed (or embedded) locally onto a device, which can then be used by any user. The software may be uninstalled on one device and installed on another within the same organization, so long as the total number of installations doesn’t exceed the number of purchased licenses.

Read the Transforma Insights report: Driving Recurring Revenue with Software

Anchored Licensing

Similar to device licensing, anchored licenses are attached to a particular machine rather than a group of devices. Often referred to as ‘Node-locked’ or ‘Workstation licensing’, the software may be embedded to the machine as part of a licensing management strategy that aims to keep tight control over access and use for application security.

Perpetual Licensing

Traditionally, it was standard practice to sell perpetual software licenses, meaning you could buy a particular version of software and own it outright. If you wished to have ongoing maintenance and support, additional fees typically applied.

Although this framework is still prevalent for many desktop applications, the emergence of modern software licensing models has seen a steady decline of perpetual as the default approach.

Metered Licensing

A metered software license limits access to software based on the number of times users sign in, the frequency at which features are used, or the amount of time the software has been in use. Metered licenses can be combined with other types of software licensing models, such as feature licensing.

Feature Licensing

By offering different levels of pricing and packaging, a feature software license allows the supplier to customize product configurations for different users, typically providing entry-level functionality at the lower end, and allowing users to upgrade to access more valuable components. Within the same organization, administrators can control access to ensure different users have access to the correct features for their role.

On-Demand Licensing

An on-demand license is a type of metered license, based on use time. The customer buys access for a defined period of time, but they can spread that time out – i.e., the application is available on-demand.

Use Time and Aggregate Use Time Licenses

Use time is a form of metered license based on the amount of time the application has been in use. The user pays ahead of time for a certain period, and once the timer runs out, they lose access until they repurchase.

Aggregate use time licenses apply use-based licensing to multiple users. An organization can set a cap on the number of hours software can be accessed across specific departments or users, aggregating the organization’s software use for billing purposes.

User-Based Licensing

Attached to a specific user, no matter the device they use, user-based licensing is another form of subscription license. It’s seen as a good option for software that retains sensitive customer information, no matter where the user is accessing the application.

Outcome-Based Licensing

Instead of traditional metrics like user count or usage duration, the price of outcome-based licensing is tied to measurable business results. This approach focuses on the value delivered by the software and requires mutually agreed-upon outcome metrics between the supplier and customer, such as increased productivity or cost savings. It incentivizes suppliers to ensure their solution delivers tangible benefits so price is aligned to value in a meaningful way.

Concurrent Licensing

Concurrent software licenses come in bulk, meaning users get a defined number of licenses to be used at the same time (i.e., concurrently) and on any device. Among the most flexible software licensing models in today’s market, it’s a cost-effective approach for organizations that have staff working in shifts or across multiple time zones, as licenses can be shared among those who have different working hours.

Floating Licensing

A floating license is essentially the same as a concurrent license, but both terms are widely used within the industry. Ultimately, these are shared licenses that can be used throughout an organization, regardless of location or device, and can move between different users to keep costs down.

Capacity Licensing

Under a capacity licensing model, customers typically pay for a predetermined level of capacity or resource allocation, which could be measured in terms of processing power, storage capacity, or other relevant metrics. The pricing structure may vary based on tiers or levels of capacity, allowing customers to choose a suitable level based on their requirements.

Token Licensing

Token software licensing models are growing in prominence, allowing suppliers to sell tokens that represent units of consumption. These tokens deplete as the software is utilized, with different features – or applications within a suite of products – requiring varying numbers of tokens. This model provides flexibility for users to allocate tokens according to their needs and priorities, making it suitable for organizations with diverse usage patterns.

Token software licensing offers benefits such as standardized tracking and management of software usage, allowing for effective cost management and budgeting. By controlling token allocation and consumption, organizations can optimize their software utilization and adjust as needed.

Trial Licensing

Trial licensing is a type of fixed term license that allows users to try before they buy. It may place limits on the features or number of users, and often requires payment details before access is granted, in the hope that users will proceed to purchase once the trial period ends.

SaaS Licensing

Customers under a SaaS license pay to access software in the cloud, rather than downloading and ‘owning’ a copy of the application. Typically licensed on a subscription basis, the SaaS licensing model is popular because it allows customers to avoid the upfront costs of purchasing and maintaining software and infrastructure. Instead, they pay on a recurring basis, and the SaaS provider handles access, updates, and maintenance.

SaaS licensing models continue to rise, with 59% of Monetization Monitor respondents indicating they intend to increase SaaS deployments by 2024.

Project Licensing

Project-based licenses are temporary licenses that allow external contributors to use an organization’s software during mutual projects.

Academic Licensing

Academic license agreements are designed for educational institutions, teachers, or students, typically with discounted pricing or different payment terms.

Offline Licensing

Offline use licenses are subscription or fixed-term licenses that also enable direct download to a device so the application can be used without the internet.

Enabling Hybrid Software Licensing Models

As software companies increasingly transition from on-premises to SaaS, hybrid software licensing models are the ‘new normal’, and this is expected to remain the case for years to come.

As such, there are multiple benefits to utilizing a software licensing service that supports all deployment and monetization models within a single platform – allowing you to streamline operations and accelerate time-to-market with standardized technology that enables self-service for end customers.

Ultimately, the various types of software licensing models each have their own quirks and intricacies to consider, but the Revenera team is always happy to offer software monetization advice, with extensive knowledge on how to grow recurring revenue across multiple sectors.

If you would like to learn more, please contact our experienced team.

If the past few years in software security and license compliance showed us anything, it’s that threat actors will continue to find a way in. The discovery of vulnerabilities and ongoing exploits demonstrate how there is no end to security iterations. New variations, additional patches, and further strategies for protection will continuously materialize.

Yet, while this space grows increasingly complicated, the evolution of technology that supports software security and license compliance is narrowing the gap for businesses. A great example is the recent release of the OpenChain Security Assurance Specification, offering a new opportunity for businesses to self-certify in security compliance.

How Should Security and License Compliance Guidance Evolve as Technology Continues to Innovate?

Security practices are always changing as new attack vectors present themselves. While security teams may not be able to predict what happens next, they can focus on creating adaptable process management in order to evolve to counter future threat actors.

As compliance guidance has expanded, businesses can now cover more bases with fewer resources. Existing Open Chain guidance for license compliance – and now security compliance – gives companies a checklist they can complete independently.

The availability of tools like code scanning, using SBOMs as part of a structured solution, and open source software management make security more approachable than ever before. Even on a consumer level, the simplest actions often have the greatest impacts:

• Train Your People – Commit to learning more about how compliance works and why it’s important will help your team better manage security over time.

• Raise Awareness – With available documentation and self-certification opportunities, you can increase the baseline awareness around security and license compliance.

• Conduct Retrospectives – Continually assess your compliance and security practices; invest in the time and resources to mitigate risk.

As technology continues to innovate, there are more resources than ever before for companies to turn to. Yet, the baseline practices of returning to your product, rechecking it over time, and being aware of what components it uses are still vital. As Shane Coughlan, OpenChain General Manager, states:

“Continually iterate, continually improve, continually evolve to make sure you’re doing the appropriate thing for your market domain.” 

How Does the Security Addition to the OpenChain Guidance Integrate into the Existing License Compliance Content?

Since its launch in 2016, OpenChain’s standard management process has become a useful set of guidelines for markets across the globe. In 2020, their open source license compliance was given a global standard, ISO/IEC 5230:2020. More recently, OpenChain has released its Security Assurance Specification.

OpenChain’s License Compliance and its Security Compliance are not identical notions, nor is one a subsection of the other. For companies that already use the license compliance guidance, OpenChian has designed the standards to work in tandem, making jumping from one to the other easy.

The compliance detailed in OpenChain Security Assurance includes the fundamental processes that should be covered and some specific security measures. Like its predecessor, it acts as a light touch that points companies in the right direction. It also provides a self-certification checklist and questionnaire.

If You’re OpenChain Conformant with License Compliance, Do You Have to Recertify in Security Compliance?

As OpenChain’s License Compliance and Security Compliance are two distinct specifications, users must recertify. Both specifications are designed as a checklist of key requirements for a quality program. Businesses can identify where they may be lacking by working through each point on this specification.

This creates a flexible jumping-off point, helping businesses to approach security at their own pace and directly in line with the specific improvements they must make. It also allows businesses to further set the ball in motion toward building up a better base of security. For example, if a company hasn’t yet told their staff they’re using open source software, they could send out a company-wide email as their very first iteration of that specification point.

With guidance like that provided by OpenChain, a range of useful tech solutions, and platforms that facilitate the software security and license compliance process, the software supply chain is evolving rapidly.

If you’d like to explore other trends and practices related to supply chain maturity, tune into Revenera’s Open Source Exchange.

Are you getting up or hitting the snooze button?

Update as of June 14, 2023:  The below blog was posted on June 13, 2023. In a typical hurry up and wait situation, the US Government has hit the snooze button for you. The June 11^th date was predicated by CISA delivering an industry-driven standard for software attestations. This work is still ongoing, therefore, OMB issued an update to memo M-22-18 via memo M-23-16 extending the deadline by 3 months for critical software and 6 months for all software AFTER the software attestation standard has been formally defined and communicated. Once that happens a firm date will be published. Please keep this in mind when reading the below. We will continue to update you going forward.

I have a vivid recollection of a moment back in 2009 when my CEO, co-founder, and I convened in our conference room in San Francisco. We engaged in a spirited discussion, pondering the most fitting term to describe the collection of items our pioneering SCA scan solution provided to our customers. At that time, no official terminology like SBOM (Software Bill of Materials) or governmental regulations such as the Cybersecurity Executive Order or the European Cyber Resilience Act had emerged, making this a truly forward-thinking discussion.

Recognizing that our customer base utilized our product to scan their code and catalog its contents for the benefit of their customers or potential acquirers during M&A transactions, we aimed to find a term that resonated. We eventually settled on “inventory,” as it aptly represented an application’s bill-of-materials—akin to what was being practiced in the hardware industry for products composed of multiple parts sourced from various upstream vendors (think about the numerous manufacturers that contribute parts to an airplane or automobile, for example).

Early on, we conceptualized a visionary notion—an overarching artifact called the “software composition statement.” This would be the deliverable of a process where Engineering and Legal leaders would jointly endorse their software application releases, instilling trust in their customers regarding the procedures followed and the reliability of the resulting analysis.

In fact, we even developed a rudimentary mockup, serving as a visual representation of what such a concept could potentially resemble:

From the beginning, we anticipated the market’s progression towards a point where it would be standard practice for software buyers to include contractual provisions in their agreements with software suppliers. These provisions would play a crucial role in ensuring accurate reporting of application composition and dependencies, as well as upholding adherence to industry best practices in secure application development.

During the past decade much work has been done via collaboration from both the public and private sectors to establish mandates, standards, requirements, best practices, and tooling. What we coined as “inventory items” back in 2009 are now known as SBOM parts. Our inventory concept has come to life in the form of a Software Bill of Materials.

This past weekend, on June 11, 2023, we surpassed our first major milestone as expressed in the U.S. Presidential Executive Order on Improving the Nation’s Cybersecurity (EO 14028), and further clarified in September by Memorandum M-22-18:

“Agencies shall collect attestation letters for “critical software” subject to the requirements of this memorandum – Within 270 days”

Hence, the crucial question for software suppliers remains: When the alarm sounded on June 11^th, did you spring into action or merely hit the snooze button?

At present, numerous software suppliers may argue that this does not affect them, citing three pivotal reasons:

1. We do not sell to the US Government
2. Our software is not classified as critical by NIST
3. We are not prepared to provide this information or feel like it puts our organization at risk to openly release composition and security information about our products

While all of these points may be valid, we need to explore each objection in more detail.

We do not sell to the US Government

Although that claim may hold some validity, it is important to consider the following scenario, and this is key: If your organization lies within the software supply chain, and your customers rely on your software to deliver their solutions to the US Government, eventually your code becomes part of the software utilized by the US Government. Consequently, your customers will inevitably require your assistance in order to ensure compliance.

The US Government serves as the initial catalyst, setting off a chain reaction with far-reaching implications. Its adoption of these regulations is just the beginning, as numerous other entities are poised to follow suit.

• The European Union (EU) is making significant strides with its Cybersecurity Resilience Act (CRA).
• Last year’s Open Source Software Security Summit in Japan facilitated a broader dialogue that extended to other geographical regions.
• CISA’s recent publication of “Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default” was a collaborative endeavor involving 12 agencies across 7 nations.
• Numerous regulated industries have already implemented comparable requirements for software transparency. These requirements apply to any software involved in controlling products that possess the potential to cause harm to humans (such as cars, planes, medical devices, etc.) or can lead to significant disruptions in human lives if compromised (such as critical infrastructure).

Therefore, the scope of these regulations extends well beyond the US Government, encompassing a wide range of sectors where ensuring the safety and security of software is paramount.

Our software is not classified as critical by NIST

While that may be true, the second major milestone is only 95 days away, and by September 13, 2023, the critical classification becomes moot, and all software sold to the US Government will require an SBOM and attestation.

We are not prepared to provide this information or feel like it puts our organization at risk to openly release composition and security information about our products

Overcoming this particular point of view can indeed pose significant challenges, considering the valid concerns raised. However, it is imperative for organizations to acknowledge the inevitability of eventual compliance. Instead of opting out, I strongly urge organizations to embrace this reality, lean in, and proactively drive innovations that directly address their concerns.

One highly effective approach is to prioritize the implementation of encrypted and signed transmission for SBOM and security data. Additionally, it is crucial to establish stringent controls over data access, ensuring that only entitled parties and authorized users can retrieve it. Although the SBOM industry is still in its early stages of development, numerous vendors are actively working on innovative solutions to mitigate these aforementioned risks.

Ok, we get it, this is important, where do we start with producing software attestations?

• Take a breath, and don’t panic!
• Communicate with your software supply chain partners to understand their needs, capabilities, and limitations
• Identify relevant standards and requirements for your industry
• Assess your controls and ensure they are up to date; implement improvements
• Establish attestation criteria
• Read up on key new technologies:
  • SLSA (Supply Chain Levels for Software Artifacts), a comprehensive security framework that serves as a common language for enhancing software security and supply chain integrity
  • GUAC (Graphical User Application Composition), a tool that simplifies the process of understanding the composition of artifacts within your applications
  • Sigstore, an emerging standard that focuses on signing, verifying, and protecting software
• Engage help; there are many experts available, including Revenera
• Continuously monitor and improve

We now have official terms, like SBOM, VDR, and VEX and mandates that capture the spirit of our discussion from back in 2009.

Our initial concept of the “software composition statement” has evolved into the official “software attestation,” acting as a declaration by the software supplier, aimed at achieving two essential outcomes:

1. That the contents of their SBOM and accompanying security reports fairly and accurately represent the composition and security risks for their application (at a given point in time)
2. That their organization has adhered to the secure software development practices (SSDF) as outlined by NIST

It is evident that change is imminent. The signs are clear: this movement will eventually encompass the globe, driven by shared goals and objectives. Recognizing and embracing this reality, and taking proactive measures today, is not only advisable but also essential. By acknowledging the evolving landscape of software regulations and the increasing demand for transparency, organizations can stay ahead of the curve and position themselves for success.

As reported in the latest Monetization Monitor, the majority of software suppliers are continuing to plan for a SaaS transition, with 59% set to increase SaaS deployments by 2024.

Although on-premises applications are largely expected to enjoy a long-tail of profitability, there’s a general notion that ‘everyone wants to be a SaaS company’, and organizations have either already shifted focus or are currently planning their move, with hybrid models on the horizon.

As remote working becomes more prevalent, on-premises software typically lacks the flexibility customers need, creating an existential crisis for suppliers who increasingly seek salvation in the cloud.

However, rather than simply replicating products for new deployments, the most advanced companies are reinventing themselves to add greater customer value.

When preparing for your SaaS transition, you should consider:

• How on-prem usage data can guide your roadmap
• The practicalities of entitlement management across your product lines
• Why Customer Success should be central to your strategy

Let’s take a deeper dive into each of these areas.

Transition to SaaS with Usage Analytics

Leadership teams frequently vow to make data-driven decisions, but on-premises products rarely have built-in usage tracking, which means the transition to SaaS often relies on guesswork.

Ultimately, if you lack objective insights into how customers really use your software – i.e., the features and functions that deliver the most value, and those that aren’t so widely adopted – your SaaS transition will suffer, as you’ll be in the dark about what to prioritize.

A wholesale ‘lift and shift’ mentality is a wasted opportunity; this is your chance to refine and innovate based on key value drivers, but the only way to obtain quantitative data on customer behavior is to integrate product usage analytics into your on-prem application.

Anonymized visibility into user journeys and aggregated information on common pathways between capabilities will provide an accurate picture of primary use cases – shining a light on the most valuable aspects of your solution while also exposing areas that could be retired when switching to SaaS.

As such, it’s highly recommended to track feature usage events and conduct user flow analysis (depicted below), empowering you with accurate insights that inform your SaaS transition with genuine data rather than general assumptions.

User flow reporting in Revenera Usage Intelligence

Those who’ve successfully made the transition to SaaS models often reference the 80/20 Pareto Principle, i.e., 80% of value is derived from just 20% of what you do.

The 80/20 rule is broadly applied across the business world, and taking time to evaluate usage data will strengthen your monetization initiatives by highlighting the 20% of capabilities you should really focus on when drafting your development roadmap.

Additionally, these insights can improve your product positioning, ensuring your go-to-market strategy is rooted in data, allowing you to target the right personas with messaging that showcases practical use cases.

Read the eBook:
Take the Guesswork out of Product Management

Centralized Entitlement Management

A fundamental consideration for every on-premises to SaaS transition is how to govern customer entitlements across your portfolio, i.e., controlling access in accordance with contract terms.

Some organizations choose to run individual enforcement systems for each product line, maintaining separate solutions for on-premises, hybrid, and SaaS deployments, which all require dedicated fulfillment and data collection mechanisms.

However, this siloed approach creates a disjointed experience – both for internal and customer reporting – with no centralized visibility into entitlements and usage, potentially impacting revenue recognition, compliance, and renewals.

As such, the transition to SaaS is your opportunity to streamline operations with purpose-built entitlement management software, allowing you to consolidate disparate systems into a unified platform that provides a ‘single pane of glass’ for all deployments, as illustrated here:

An Entitlement Management framework for both on-prem and SaaS deployments

The ability to manage SaaS use rights alongside on-prem entitlements enables you to offer flexible pricing and packaging options, easily bundling products together – regardless of deployment and monetization models – to meet varying customer needs.

A centralized entitlement management system also facilitates end customer self-service, allowing administrators to allocate use rights and monitor utilization rates, enhancing the user experience and reducing support calls.

In the modern world, customers expect usage data transparency, ensuring they can track adoption to gauge value and stay on top of contractual obligations, avoiding surprise bills in the event of overuse. Openly providing these insights has dual benefits for both buyers and suppliers, so centralizing entitlement management should be a cornerstone of your SaaS transition strategy.

Download the IDC PlanScape Report:
Future of Digital Innovation: Managing Customer Entitlements Efficiently

Exceeding Customer Expectations

Customer Success has become a critical function for SaaS providers, as today’s buyers expect uninterrupted services that deliver continuous value.

Customer Support is generally a reactive discipline, firefighting issues as they arise, but Customer Success should be proactive from day one – helping users gain immediate value in the onboarding process, and communicating changes or potential outages ahead of time to help them prepare.

Closely aligned to Support, Product, and Engineering, Customer Success Managers (CSMs) are vital as you transition to SaaS model deployments, relaying customer concerns, ideas, and requests to the right people to ensure your platform is primed for growth with strong retention rates.

SaaS monetization revolves around the guiding principle of growing Annual Recurring Revenue (ARR), allowing you to better forecast for the future in comparison to traditional, perpetual sales that are ‘lumpy’ in nature.

As such, Customer Success teams need to be laser-focused on renewals, developing long-term relationships that are dedicated to delivering value.

Access to usage data is essential, allowing CSMs to have informed conversations about utilization rates and how to maximize value, while also monitoring at-risk accounts with low activity in a bid to avoid churn. Again, this is where centralized entitlement management supports the move to SaaS.

Share this with your friend in Finance:
The CFO’s Ultimate Guide to Successfully Moving to SaaS

SaaS Transition Consultancy

The transition from perpetual to SaaS frameworks can be a rocky road, but the Revenera team has vast experience in helping suppliers introduce cloud deployments with flexible software licensing solutions that allow you to adopt new, hybrid monetization models.

Following the steps outlined above will allow you to:

• Grow ARR with a platform that enhances your most compelling use cases
• Streamline operations with a single system of record for data and insights
• Reduce time-to-value and increase retention with Customer Success

Whether your on-prem customer base knows it or not, they can drive your SaaS transition roadmap with telemetry data that reveals your most compelling features, as Extensis found when they embedded the ‘Voice of the Customer’ into Development.

Achieving a ’cause and effect’ understanding of how and why customers use your product, breaking down silos by consolidating back-office infrastructure, and committing to build long-term relationships will boost revenue optimization, which should be the ultimate goal as you transition to SaaS.

Your journey to the cloud may have been delayed, but as the ancient Chinese proverb suggests:

The best time to plant a tree was 20 years ago.
The second-best time is now.

If you need advice on your SaaS transition project, our expert team is only a contact form away.

In the meantime, you may find these resources helpful:

• eBook: The PM’s Ultimate Guide to Successful SaaS Implementation
• Case Study: Infor F9’s New License Model is Built for the Cloud
• Case Study: Teradici Drives Growth Through Move to Subscription Model

When we talk about security related to the software supply chain and third-party software management, it’s key that the tools you use provide detailed reports on the known and unknown vulnerabilities inside applications along with the level of exploitability of those vulnerable components. Absent that, all you have is a listing of SBOM parts without much to act on.

Typically, you don’t want to co-mingle security information with an SBOM because it’s too dynamic—it’s always changing. You want an SBOM that has all of the composition and the licensing information (it’s static from version to version of your application) and then you want a separate document that’s a snapshot of the security state that cross-references the parts in the software bill of materials. To accomplish this, there are two approaches, both provided in the current release of SBOM Insights. 

Vulnerability Disclosure Report (VDR)

A Vulnerability Disclosure Report (VDR) comes from either a software supplier or a third-party and is used to demonstrate proper and complete vulnerability assessments for components listed in an SBOM. NIST SP 800-161: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations defines VDR as:

Enterprises, where applicable and appropriate, may consider providing customers with a Vulnerability Disclosure Report (VDR) to demonstrate proper and complete vulnerability assessments for components listed in SBOMs. The VDR should include the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on a component or product. The VDR should also contain information on plans to address the CVE. Enterprises should consider publishing the VDR within a secure portal available to customers and signing the VDR with a trusted, verifiable, private key that includes a timestamp indicating the date and time of the VDR signature and associated VDR.

The VDR shows that you have done a proper job of disclosing all the vulnerabilities that exist for all the parts in your application(s). Think of a VDR as everything that has been reported against every single part in the application(s). It should contain the following:

• All vulnerabilities affecting a product or its’ dependencies (both direct and transitive)
• Analysis describing the impact (or lack thereof) that a reported vulnerability has on a product or dependency
• Mitigation plans to address the vulnerability
• A VDR signature with a trusted, verifiable, private key that includes a timestamp indicating the date and time of signing

A VDR should include two specific areas of information. The first is an enumeration of vulnerabilities that will give you the source, severity score, common weaknesses, and all the dates. The second bucket of data is a reference to the part(s) in the SBOM with which the vulnerability is associated.

A word of caution. A VDR report is most likely going to be fairly large and may contain irrelevant content. Just because some vulnerabilities are reported against a component, does not necessarily mean they ultimately impact your application or that there is impact to the components you’re using. It all depends on context and how the application is used. Each vulnerability really needs to be assessed for both impact and relevance to your application as it is used by your customers.

Vulnerability Exploitability eXchange

The Vulnerability Exploitability eXchange or VEX is the next artifact important to security transparency. VEX became popular with the NTIA Software Transparency initiative and now CISA picked up the ball and is running with it as an important element to the U.S. Executive Order (14028) issued back in May 2021:VEX became popular with the NTIA Software Transparency initiative and now CISA picked up the ball and is running with it as an important element to the U.S. Executive Order issued in 2021:

The goal of Vulnerability Exploitability eXchange (VEX) is to allow a software supplier or other parties to assert the status of specific vulnerabilities in a particular product.

Think of it as a negative security advisory. It’s used to explain what you’re going to do about a vulnerability or why a vulnerability does not impact your application. A VEX report should include:

• Analysis describing the impact (or lack thereof) that any vulnerability has on a product, product family, or organization
• Plans to address the vulnerability
• A VEX signature with a trusted, verifiable, private key including a timestamp indicating the date and time of the VEX signature

If we break up the VEX report into separate elements, it’s important to show the specific vulnerability information—similar to what’s in a VDR—as well as an analysis that provides the disposition of the vulnerability in your product.

VEX is a report your vendor or supplier will hand you if you’re embedding software or purchasing an application for enterprise use. Or, if it’s an SBOM for your product, your security or engineering team will annotate the vulnerabilities that are reported against your product to inform your downstream software supply chain and customers of true-positive risk in your application and your plans to address the false-positives.

Net, a VEX report is an opportunity for you to focus your analysis of reported security issues to only those items that are true positive and are actually exploitable via your application.

CISA recently released two new documents that might be of interest for further reading:

1. Minimum Requirements for Vulnerability Exploitability eXchange
2. Types of Software Bill of Material Documents

Every once in a while, we need to brag a bit about our accomplishments. Today we are happy to announce that ComponentSource has presented our Software Installation business with several achievements from their 2023 Awards for both leading publishers and individual products: 

• Revenera – Top 25 Publisher 
• InstallShield – Top 50 Product Award 

• InstallShield Premier – Top 50 Product Award 
• InstallAnywhere – Top 100 Product Award 

ComponentSource is one of the world’s largest global marketplaces and community for reusable software components for all platforms and development tools. The awards given to the Top 100 Bestselling Publishers and Top 100 Bestselling Products are based on the total sales dollar value of orders placed by customers during the 2022 year. The awards have been around for the last 17 years and—given they are based on real customer orders—we are honored to be named and associated with such a long-standing tradition.  

“As in previous years, these awards are based on orders we received from our global customers. They represent a true global market snapshot for commercial software components and development tools in 2022,” says Sam Patterson, ComponentSource CEO. “We believe our awards represent accurate real-world data on how our customers are using these components and development tools in their latest projects.”  

Here’s a little more about our solutions. We encourage you to learn more and contact us if you have a question about our InstallShield or InstallAnywhere solutions.  

InstallShield 

InstallShield is the industry standard for developers creating installers for Windows desktops, servers, virtual and cloud platforms. Using Revenera’s Cloud License Server (CLS), you can now configure InstallShield to your CLS and build without any friction in cloud environments. You no longer need to configure a license server and upgrade for every release. 

Key product features include: 

• Support for MSIX 
• Seamlessly build on cloud platforms using Cloud License Server 

• Simplified builds within Docker 
• Integration with Visual Studio 
• And more 

InstallAnywhere 

InstallAnywhere is the leading multi-platform solution for developers creating installers for physical, virtual and cloud environments. More developers choose InstallAnywhere to build reliable and consistent installations because it offers an ideal combination of ease-of-use and powerful functionality.  

Some of the features include: 

• macOS Ventura support and support for Apple M1 
• Define apps for file associations in Windows 
• Action to enable 8.3 naming convention in Windows 
• Implement Linux best practices and reduce steps for managing RPM and DEB prerequisites by installing dependencies from Linux package managers. 

• Create Java-Based installations for multi-platform applications, including Windows 10 
• And more 

What is GPL?

The GNU General Public License, often known as copyleft or viral, grants permission to use or reuse or modify source code to make derivative works with a condition that if you distribute your program to others, it requires you to license the derivative work under the same license. There is a catch to this, i.e., by agreeing to the GPL license, (if you plan to redistribute) you must make the source code wholly available to users and allow further modifications and retribution of your product.  This makes it unpopular to authors who make money using proprietary software.

GPL with SaaS Exception:

GPL triggers during distribution, so it makes SaaS (Software as a Service) products immune to some extent. SaaS is a way of delivering the applications via the Internet without installing or distributing the source code to the user. So, making your product available via the Internet does not qualify it as a “Distribution,” which does not trigger the GPL condition. Also, SaaS applications which use JavaScript library will be at risk since, in some legal circles, it is considered a Distribution that triggers GPL condition. Net, it is advisable to stay away from GPL-ed JavaScript Library for your SaaS applications.

What is AGPL?

Section13 of the GNU Affero General Public License v3.0 (AGPL-3.0) closed the SaaS loophole which is one of the major differences between GPL and AGPL. In simpler terms, AGPL is like GPL with an exception that GPL is only triggered if you distribute your derivative work. AGPL broadens this trigger to activate if you let people use your derivative work even over a server connected to the network.

Concerns or Risks Companies face?

There are two major concerns or risks faced by SaaS companies or others nowadays by using open-source components, one is License Compliance and other is security Issues.

• License Compliance: Due to unawareness of license compliance by companies may lead to potential legal cases. For example, SaaS products are less immune to GPL but if they use AGPL they must comply and release their product under open-source compliance. Using unknown licenses will carry the same risk, because by default if a component is not licensed, it is not given the right to use.
• Security Issues: In this modern technological era, free and security doesn’t come as one package. When you are using open-source components in your products, you are exposed to certain risks which are vulnerabilities and bugs. One good thing about the open-source community is that it is vocal and active regarding vulnerabilities. Once identified, a patch is usually released soon. The Common Vulnerabilities and Exposures (CVE) system provides a reference-method for publicly known information-security vulnerabilities and exposures. Recent examples are Apache Log4j which caused a massive surge in the community but was later patched and resolved. Another is Severe Security Flaw Found in “jsonwebtoken” library Used by 22,000+ Projects

Software Bill of Materials (SBOM)

The best way for companies to deal with license compliance and security issues is to prepare a thorough SBOM. A Software Bill of Materials in an inventory list of all software components and dependencies which are present in a given product. This includes a list of all open-source components with its versions along with license and vulnerabilities, giving an opportunity for the companies to stay ahead in terms of license compliance and security risks.

What does an SBOM offer?

Revenera provides services for companies to prepare a truly pure and relevant SBOM for their products. Revenera SBOMs are categorized into priority levels based on license and CVE scores which will help companies to investigate and resolve any risks they carry in their product(s).

Disclaimer: This post is for information purposes only. Please consult an attorney or inside counsel for any legal advice.

The past decade has been a whirlwind for the software supply chain. As the use of open source software (OSS) has become more pronounced, more businesses than ever before are using SBOM (Software Bill of Materials) solutions in order to better manage OSS and third-party components.

An SBOM is a formal, queryable record containing the details and relationships of various components using in building software. Some SBOM elements include:

• Author and timestamp
• Component version
• Supplier information
• Unique identifiers
• SBOM part dependency relationship

Despite a mass movement to SBOM awareness and having more appreciation for open source conformance and compliance, not all industries are moving at the same pace. Some industries, like automotive, medical device manufacturers, and government sectors, are more rapidly adopting standard practices.

SBOMs When the Consequences are Truly Dire

According to research published by the Linux Foundation in 2022, roughly 78% of organizations were expected to produce an SBOM in 2022 with a higher concentration of SBOMs coming from a few fundamental sectors.

These industries typically have one thing in common; their applications have real-world consequences that impact human life. With that in mind, if anything were to go wrong, there would be a much higher level of consequence.

If a car were to “malfunction” because of an open source vulnerability while someone was driving down the road, the consequences could be disastrous. Likewise, security flaws inside insulin pumps or pacemaker programming machines could mean life or death.

There are a number of reasons why these high-risk industries are turning to SBOM solutions:

• Gravity of Impact – Industries that have an element of human risk have much more to lose than other sectors. Ensuring absolute compliance and security has to be a priority for them.

• Current Practices – Government, automotive, and medical industries already have a lot of protocols they follow to ensure safety. With these already in place, extending them to cover open source compliance and security is not as much of a large jump.

• Accountability – With more to lose, the consequences for failing to comply are much higher. As risk increases, the need to comply also steadily rises. These industries are held to more accountability because of their interaction with consumers and possible outcomes of failure.

SBOMs are vital for knowing exactly what’s inside the code these organizations either place in their applications or purchase to put in their products. Companies can eliminate manual record-keeping efforts and get full end-to-end visibility over the open source code they use. Having that insight up and down the software supply chain is even more critical. For businesses that deal with real-world risk, rapid insight into new vulnerabilities in the code they produce and/or consume has not just bottom-line impact, but life and death consequences.

The Evolution of SBOMs

Once upon a time, entire industries would shy away from using open source software. At present, this couldn’t be further from the truth. OSS has now weaved itself into sectors around the globe, forming a core part of major software deployments.

As OSS has become integral to software as a whole, the software supply chain is evolving in order to make its use as safe and secure as possible. SBOMs are a primary method of ensuring compliance and security, with their use only becoming more popular over time.

In May of 2021, the Biden administration issued an Executive Order (EO) to better secure the nation’s software supply chain. Any organization doing business with the federal government will be required to provide a software bill of materials for all software applications. The EO urged the private sector to follow suit. Since then, the federal government issued updates to the EO in its National Cybersecurity Strategy on March 2^nd.

There are similar regulations happening across the globe, including multiple EU agencies taking action as well as the EU published a proposed Cyber Resilience Act aimed at safeguarding consumers and businesses using products with a software digital component.

Industries that have more to lose should be ahead of the game, having already made SBOMs a core part of their application development and any product produced and shipped to their customers. Over time, we’re likely going to see SBOMs become the go-to solution for application software inventory across all industries.

If you want to learn more about managing Open Source compliance and how the software supply chain is maturing, be sure to tune into this Revenera Open Source Exchange.

For more about SBOMs, please check out this resource.