Traditionally, software providers have implemented Software Development Lifecycle (SDLC) management procedures to ensure a structured and consistent approach to software development practices, ensuring that all stages of the SDLC process (planning, design, build, release, maintenance, support and decommissioning) would be executed in a controlled manner. While these procedures have been implemented to achieve high-quality functional products, they do not necessarily address the security element.
Steps to “secure the product” are typically an add-on to the SDLC process, and in many organizations, security is treated as a “nice to have” check or a last step in the product validation process. Nonetheless, this little attention to security is not to be long-lasting. Security by design practices and product built-in security features are becoming, more frequently, non-negotiable requirements for large corporate customers of software products. This is due to the upsurge of third-party software vulnerabilities and the high impact of the materialized supply chain attacks experienced during the past few years (e.g., SolarWinds, Log4j, 3CX, MOVEit).
As a result, corporate customers, especially those with high purchasing and bargaining power, are not just interested in new, revolutionizing software products but also in secure, safe-to-use products. For software manufacturers and vendors, this means security is no longer an option but a “must have,” and when in doubt, we should ask ourselves a very simple question: If our customers entrust us their most important asset (data), shouldn’t we be delivering an equal level of security, trustworthiness and transparency in the software products we offer to them?
Developing great software with security-by-design
But implementing a Secure Software Development Lifecycle (SSDLC) process is not so simple. The first step is to ask our organization if we are ready to have such process in place; to not just develop great software but do it with security-by-design principles in mind. Leadership commitment to security becomes paramount here. When there is engagement from the top, security goes beyond a nice-to-have and becomes a management statement, a company principle, a shared team value, a tangible objective, a priority during refinement and planning, a mandatory set of steps and checks across SDLC, a KPI/KRI in management reporting, and so on. When this occurs, security is no longer a separate “to-do,” but it´s embedded in the DNA of our teams and we start delivering products in line with the commitments we have made, moving away from justifying to demonstrating our robustness, reliability, sustainability and transparency.
In February 2022, NIST published the Secure Software Development Framework (SSDF) Version 1.1, describing recommendations for embedding security in all stages of the SDLC process. In this framework, NIST proposes practices that appear to be organized into four groups:
- Prepare the Organization (PO): Organizations should ensure that their people, processes and technology are prepared to perform secure software development at the organizational level.
- Protect the Software (PS): Organizations should protect all components of their software from tampering and unauthorized access.
- Produce Well-Secured Software (PW): Organizations should produce well-secured software with minimal security vulnerabilities in its releases.
- Respond to Vulnerabilities (RV): Organizations should identify residual vulnerabilities in their software releases and respond appropriately.
All four groups of practices provide high-level principles and underlying notional examples to satisfy the criteria of what a secure software product should be. In each one of these practices, NIST also touches on how we should manage the security risks introduced by third-party software components (approximately 20% of the entire framework).
The use of third-party components, whether vended or Open-Source Software (OSS), continues to grow as the software development community sees that component-oriented development saves time and enhances the quality of the custom software. Research shows that 76% of the total codebase used is usually OSS code, meaning that the weight of OSS alone in our software composition is rather significant. But OSS and third-party components, in general, continue to be overlooked, or we simply continue to fall under the assumption that if they are widely distributed and used, they must be safe to use. Thus, there has been a false sense of security when it comes to third-party components risks. ISACA’s 2022 Supply Chain Security research shows that for the surveyed companies:
- Nearly 1 in 5 third-party assessments do not include cybersecurity and privacy assessments.
- 39% have not developed incident response plans with vendors in case of a cybersecurity event.
- 49% say that they do not perform vulnerability scanning and penetration testing on the supply chain.
- 61% say their risk assessments do not include supply chain risk assessments specifically for devices using artificial intelligence (AI).
However, because of recent software supply chain attacks, companies are trying to get more visibility into their supply chain dependencies and understand the risks these introduce to their environment. In the following section, I would like to expand upon the NIST Framework and shed light on what practices software manufacturers, vendors and customers can apply to manage third-party components risks effectively as part of the SSDLC process:
- Perform a Purpose, Feasibility and Maintainability Study before introducing a third-party component: Just as when sourcing a vendor of tool or professional services, the importance of the procurement process of a third-party software component should not be underestimated. For that reason, it is important to have some ground rules in place to select and implement the adequate component:
- Define Purpose: Evaluate multiple components to determine which one best satisfies the functionality that is required. Document the pros and cons of at least three preferred components.
- Determine Feasibility: Evaluate the cost of developing your own functionality vs. utilizing a third-party component, both short and long term. Evaluate the feasibility and cost of integration efforts, and the resources to maintain this.
- Analyze Maintainability: Often overlooked, due to the tight timelines to deliver a product short-term, the maintainability of the component should be a decisive factor to decide if it should be used. Simple questions to address include: Is there sufficient documentation and support about the component? Is there a product roadmap? Is the component being updated regularly? Can we keep up with all the updates? Are we able to prevent legacy components?
- Third-party software components should also undergo a third-party risk assessment:
Business Impact Assessments (BIA) and Third-Party Risk Assessments (TPRA) have been widely adopted as the preferred methodology to understand vendor risks and reject or accept vendors depending on whether they fit within our risk appetite posture. Vendors of tools and services are most commonly subject to these exercises while third-party components of our own software products are often exempted. Whether it is an application for email delivery, a solution for translations, or an AI-driven chatbot, all application-like components should be assessed against the security and privacy-related criteria for selecting vendors. Such criteria can include our encryption requirements, third party’s patch management and vulnerability disclosure program, product security incident response capabilities, the review of SOC 2 reports, ISO 27001 Statement of Applicability (SOAs), and data protection policy review, among other critical elements that the organization finds important. A TPRA that results in risks or findings should be used to decide whether to approve the use a component and to periodically review and follow up upon it.
- Utilize Software Composition Analysis (SCA) and SBOM to strengthen security:
Just as we have an interest in the ingredients of the food products we consume, having an interest in the ingredients that make up our software products can give us meaningful information about the security, compliance and maintainability of these. Leveraging automated solutions such as Software Composition Analysis (SCA) to analyze SBOMs (Software Bill of Materials) can be a good start to being more in control of our software products and to proactively manage supply chain risks. Depending on the format, whether it is SPDX, CycloneDX or SWID, SBOMs can provide us with the data provenance of our products components, such as manufacturer name, package version, licensing information, vulnerabilities, package relationships, services, dependencies, and much more. Such provenance information can help us identify license conflicts and compliance issues, security vulnerabilities, VEX (Vulnerability Exploitability Exchange), file integrity, and potentially identify “high risk” components, e.g. abandonware (not updated in two years or more), empty packages (no source files), and native binary code (executable code not usually associated with the type of package, which can be used as a an attack vector). As a result of such analysis, we can decide which components must be sanctioned (blacklisted) and what others are approved (whitelisted).
The use of SBOM in our third-party risk management procedures and as an underlying element of the SSDLC Process drives the transparency between the developer community, software manufacturers, vendors, and customers. It puts us one step ahead of zero-day threats and supply chain attacks, while at the same time helps us to deliver better quality sustainable software.
Other important considerations
In the process of securing our products against supply chain attacks, the implementation of SSDLC policies and Third-Party Risk Management procedures alone will not suffice without the formal appointment of Product Owners (POs). Whether the ownership lies at the aggregated product level or a component basis, it is essential that someone within the organization takes ownership for the secured end-to-end lifecycle management of the product and its components.
In addition, an up-to-date inventory of all products and underlying components, with a designated risk categorization (e.g., high, medium, low risk), should be maintained. Inventorying what we have, and especially what we approve or don’t approve, is essential to gain visibility into our product risk landscape, its complexity, and the business impact if something goes wrong.
Finally, as the saying goes, “Trust, but verify.” A process can never be labeled as effective if we don’t perform an independent review to verify it works as expected and that risks are identified and controlled. At a minimum, high-risk products should be audited against the expected secured development lifecycle practices and attention should be given to their third-party composition and dependencies.
Understand what is beneath the surface
Learning to treat security as a key element of the design, build and implementation of our software products is a journey that takes awareness and commitment, but understanding the impact that third-party components play in achieving the desired level of product security is one step further that not everyone is prepared for. If you truly care about the quality of the products you are offering, then check and challenge what is beneath the surface, the relationships and dependencies at multiple levels. Eventually the final product will always be the aggregation of all its components, ways of working, checks and procedures involved during its lifecycle, and we will only be able to secure it once we achieve full visibility into the weaknesses and improvement opportunities across all these parts.
