devopsy.kinsta.cloud

Tag: Software Supply Chain

  • Secure Software Summit: Securing Software With Zero-Trust

    Secure Software Summit: Securing Software With Zero-Trust

    With the increase of supply chain attacks on everything from logging software like Log4j to takeovers of important JavaScript packages to compromises of network utility tools like SolarWinds, more and more organizations are recognizing the need to adopt a zero-trust mindset. Zero-trust can improve security, reduce risks and give organizations greater confidence in the integrity of their IT infrastructure and applications. To correctly set up a zero-trust architecture, you need to understand what it actually takes to make systems zero-trust.

    Zero-Trust Definition and Guiding Principles

    Due to the rise of interest in zero-trust, many misconceptions have built up that bear correcting. 

    • Zero-trust is not a product or tool. In fact, there is no single tool you can apply to an environment to configure a full-stack zero-trust implementation. Rather, zero-trust is more about creating and refining an architecture and applying a consistent mindset. 
    • Zero-trust is a never-ending journey. It is not a destination. You are never done; never finished setting up zero-trust, because software applications and IT environments continuously evolve. As your environment evolves, part of applying zero-trust is going back and reassessing everything you are doing on a regular basis to ensure it complies with the principles of zero-trust and covers all your software and technology assets. 
    • Zero-trust does not mean your environment cannot be hacked or breached. On the contrary, under zero-trust you constantly assume your environment has been breached. Zero-trust emphasizes building defensive layers that reduce the potential impact of any hack or breach and protects your assets and data.

    So, what is zero-trust? Zero-trust is a framework and approach to security that assumes an organization’s IT assets — software, networks, data — are constantly at risk and must be secured through continuous verification of the identity, and the application of least privilege principles against any identity — human or machine — operating inside the IT environment. The core of zero-trust is the lack of inherent trust for any identity as a managing approach to building more resilient applications and segmented risk.

    Zero-trust has several key guiding principles.

    1. Verify all identities, all the time, using a strong form of authentication — not just username and password. Specifically, use strong forms of authentication, such as multifactor authentication. This principle applies not only to human users but also to all devices, bots, services, APIs and partner systems accessing your environments. They must be verified every time they seek access and continuously while they are active inside your environment. 
    2. Always assume your environment has been breached. From this starting point, design your systems to reduce the blast radius and protect your assets as if an attacker is continuously present and moving within your environment to perform malicious acts — data exfiltration, system takeover, or other forms of abuse. 
    3. Always enforce least privilege for everyone and everything operating in your environment. Least privilege means limiting access only to systems, applications, data and services required for each task or interaction. To properly apply least privilege requires an understanding of expected behavior for applications and services, what they should and should not be doing, and also creating a sense of context. Applying least privilege with context is also dependent on assessing the security posture of any device, service, application, API or identity seeking access. Your zero-trust policy enforcement engines should always interrogate inbound and ongoing connections to understand where an identity is coming from, what it is trying to connect to and the current security posture of that identity. The answers to these questions should inform and shape least privilege permissions and provide additional insight into the risk of providing access.
    4. Segment your environment to limit horizontal traversals or pass-through attacks. This is closely related to least privilege. The bottom line: Do not award any identities carte blanche access to your network, applications data or infrastructure. Only allow identities access to the portions they truly need to perform their task, and only while they are performing that task. 

    Using Zero-Trust to Secure Software and Software Supply Chain

    The conceptual language of zero-trust makes it sounds like an identity architecture and network security approach, floating above developers. For building and deploying secure applications, developers and DevOps teams must also adopt a zero-trust mindset. In fact, there are clear synergies between zero-trust and application security — and particularly with regard to open source software (OSS). OSS developers may not spend sufficient time and energy on securing their code because it is not what they like about writing software. For this reason, if you are including OSS code (and nested OSS libraries) in your applications and environments, then you have even more reason to apply zero-trust frameworks. 

    A useful way to think about this is to consider zero-trust as applicable from the inside out, from the outside in and to everything in between linking internal and external, applications and APIs, code and integration/deployment pipelines and partner environments. Properly executed, zero-trust allows your developers to go faster but also be safer. Additionally, it is useful to view zero-trust through the confidentiality, integrity, availability (CIA) lens. You should design your zero-trust architecture to deliver these elements in a priority hierarchy that maps to your business needs. There are a few different ways to implement zero-trust principles in the software supply chain. 

    Assume Your Code has Been Breached and is Insecure

    Conduct a software asset inventory, looking at and categorizing all code running in your environment. This makes it easier for you to identify unauthorized changes and build more resilient applications. Set up mechanisms to detect unauthorized changes or anomalous software behaviors. You may want to apply these guidelines to close partners and their software and supply chain, as well. Remember that attacks may be from you, through you, or at you. 

    Manage Identities Carefully

    Analyze and categorize user entitlements to set a baseline for least privilege. Conduct an inventory of all identities active in your environment to identify known identities (and quickly recognize unknown identities). Set up mechanisms to analyze the behavior of identities to spot anomalies and create a baseline for context and behavioral privilege and access policy decisions. Include partner identities in this inventory: Your greatest risk may come from unsecured partners that attackers use to gain access to your environment. The inventory should also include service and admin accounts. The inclination is to set their privileges and forget about them, often awarding broad access so as not to slow them down and also potentially providing an unmonitored backdoor to attackers. 

    Take Inventory and Lock Down Integrations

    Inventory your external and internal supply chain. This includes all dependencies in the code, services called, APIs exposed or accessed and tooling for developing, hosting, integrating and building applications. For example, you may want to analyze your CI/CD pipeline and deployment environments through the lens of segmentation and least privilege to limit access depending on the pipeline stage. Put in place measures to segment the software environment and prevent lateral movement, like application sandboxing (but make sure to also tightly secure your sandboxes). 

    Code Assessment

    Developers need to apply threat models to their code and adopt the mindset of considering what an attacker might access and what they might do should they compromise an application or the surrounding supply chain. Obviously, for all code — and especially OSS code – developers will need to continuously look for vulnerabilities and scan code using tools like static code analysis and dynamic application security testing. Zero-trust means continuous verification of your own code, not just the entities using the code.

    Zero-Trust Takeaways

    As we continue towards a future of more complex and integrated application environments and more usage of OSS code for core application functionality, the zero-trust future becomes zero-trust forever. It will simply become a way of life in application development. That said, we should keep in mind four key guiding principles. 

    Know Your Current State—Be aware of where your environment stands and your security posture, and direct and indirect impacts of security vulnerabilities.

    Assume Breach—Be able to identify anomalous behavior and continuously consider what could be done by an attacker if your app was used maliciously?

    Assess—Continuously assess the status and changes in the environment. Ask questions like: Who has what, when and where? Where do your integrated partners and vendors stand in terms of security?

    Continuous Improvement—Periodically assess and compare your zero-trust efforts against desired security posture and make improvements that align with objectives around confidentiality, integrity, and availability. Constantly guard against risk. 

    These four principles map to five key takeaways that any developer, application security team, DevSecOps team or platform team can apply today and forever.

    • Review your environment with a zero-trust lens 
    • Recertify all identities continuously
    • Establish baseline app and identity behavior
    • Focus on detection and prevention of attacks
    • Design applications for resilience

    Following these guiding principles and basic framings will ensure your zero-trust journey creates strong defenses that help protect your development supply chain from the outside in, inside out, and with integrated partners.

    The Secure Software Summit brought together the world’s leading innovators, practitioners and academics of secure software development to share and teach the latest methods and breakthroughs on secure coding and deployment practices. If you are about developing, releasing and securing software, delivering new features fast and building things right from the start, click on the link below to get access to all of the sessions from this summit.

    https://go.shiftleft.io/secure-software-summit-2022-replay

  • Pulumi Adds Business Critical Edition to Infrastructure Management Platform

    Pulumi Adds Business Critical Edition to Infrastructure Management Platform

    Pulumi today added a Business Critical edition of its Cloud Engineering Platform that provides large enterprises with additional security and compliance features, premium 24×7 support, training, professional services and a self-hosting option.

    In addition, the company announced that Pulumi Enterprise and Business Critical editions are now available via the online marketplace run by Amazon Web Services (AWS), with future availability on other marketplaces planned.

    The Cloud Engineering Platform from Pulumi enables DevOps teams to use Pulumi Packages to create reusable components for automating IT infrastructure provisioning. Those can be embedded within workflows and applications using an application programming interface (API) that Pulumi has exposed. IT teams can define a Pulumi Package in the programing language of their choice.

    Aaron Kao, vice president of marketing for Pulumi, said the Cloud Engineering Platform from Pulumi provides an alternative to managing infrastructure-as-code (IaC) that can be centrally managed more easily than open source tools like Terraform.

    Pulumi reported that adoption has accelerated across enterprises around the world with more than one million downloads per month. The company claimed it has seen 350% year-over-year growth of its enterprise customers, such as Mercedes-Benz, in the last 12 months.

    IT organizations in general are looking to bring some order to chaotic provisioning processes to avoid misconfigurations that often result in, for example, a developer leaving a port open; that open port leaves a vulnerability through which data can be exfiltrated.

    As organizations focus more on software supply chains in the wake of recent high-profile breaches, it’s only a matter of time before more questions arise about how cloud infrastructure is being provisioned. Much of the concerns organizations already have about cloud security don’t stem from the platforms themselves. Rather, it’s the processes employed to provision infrastructure under a shared cloud security responsibility model that results in so many vulnerabilities. Developers often assume the cloud service provider is securing configurations, only to discover later that it was their own responsibility to validate those configurations. Security teams, meanwhile, can’t keep pace with the rate at which cloud infrastructure resources are being provisioned.

    Centralizing infrastructure management is especially important as the number of cloud platforms IT organizations manage continues to expand and the rate at which applications are built and deployed shows no sign of slowing, noted Kao.

    It’s not clear whether development or IT operations teams will ultimately wind up managing the provisioning of infrastructure. Pulumi is making a case for a platform that enables those teams to more closely collaborate within the context of a set of policies and DevSecOps best practices that the IT organization defines.

    It may be a while before the bulk of enterprise IT organizations are able to exercise the political will to regain control over IaC provisioning. However, in the absence of guardrails that allow IT organizations to make sure infrastructure is properly configured, it’s only a matter of time before tougher questions are asked about how software supply chains are managed.

  • 4 Reasons Software Developers Need a Bill of Materials

    4 Reasons Software Developers Need a Bill of Materials

    The recent Log4j/Log4Shell vulnerability was a wake-up call that threats aren’t going to wait until the industry gets up to speed on software supply chain security. While the Log4j open source component vulnerability caught us all off guard, it did highlight the need for software vendors to be more proactive in disclosing the composition of their products. It’s become painfully clear that analyzing open source libraries and third-party code should become standard practice to understand their makeup and the potential risks they introduce in commercial software applications.

    Unfortunately, relying on open source projects to provide visibility into security vulnerabilities isn’t going to work. In most cases, these projects are grossly underfunded. At the time of the Heartbleed vulnerability, for example, OpenSSL received very little funding. Yet, open source usage increases each year. It’s imperative that commercial software organizations contribute to open source projects they use and share responsibility for the security of these products.

    In addition to open source libraries, most vendors source third-party code from contractors or for-hire development organizations. Without documentation of the composition of the code developed by third parties, it’s impossible for commercial software vendors to proactively identify and manage risk before it’s implemented in their development cycle.

    Using Software Composition Analysis (SCA) Tools

    Where a software bill of materials (SBOM) is not provided, the onus should be on commercial software vendors to create one. This can be accomplished using software composition analysis (SCA) tools that analyze binaries and do not require access to source code. They can generate SBOMs to identify open source or third-party components in use, as well as track and manage security risks in the software supply chain.

    Creating a comprehensive SBOM provides other benefits, since most open-source projects and contract developers are only likely to publish direct dependencies (if at all) and not look further into the dependencies of dependencies, and so on.

    Four Benefits to Consider

    Meanwhile, commercial software vendors can expect their customers to soon start demanding SBOMs since this will be a requirement under the cybersecurity executive order. Given this evolving landscape, commercial software vendors should consider the following four benefits for proactively implementing an SBOM program to govern the products they build:

    • Gain visibility into software supply chain risk to identify, reduce and remove vulnerabilities in reused software (i.e. open source and third-party). SBOMs provide data for business decisions on the software you have reused and purchased. It’s better to discover these risks before your customers do.
    • Preemptive supply chain qualification to ensure compliance with future requirements. SBOMs will soon be a requirement for doing business with the U.S. federal government. Suppliers that meet the SBOM requirements during procurement will be given preferential treatment.
    • Improved security and downstream benefits that come with risk management and mitigation. Avoiding, detecting and remediating security risks before they become embedded in a product pays huge dividends during development and deployment. You’ll be better prepared for the next security event.
    • Common understanding of software assets that comes with a standardized SBOM shared amongst developers, suppliers and open source projects. An SBOM becomes a way to communicate software contents and dependencies within and outside an organization.

    Taking a proactive approach to the software supply chain by creating SBOMs and demanding the same from suppliers will enable commercial developers to be better prepared for the next Log4j/Log4Shell vulnerability. It will also allow them to improve the software supply chain security posture of their end customers.

  • Linux Foundation Survey Sees Rise in SBOM Use

    Linux Foundation Survey Sees Rise in SBOM Use

    A global survey of 412 organizations published today by the Linux Foundation found nearly half of respondents (47%) producing or consuming software bills of material (SBOMs), and more than three-quarters said they expected to produce or consume them in 2022.

    SBOMs have become a bigger area of focus in the wake of a series of high-profile software supply chain-related breaches. The breaches involved application components compromised by malware that had been surreptitiously inserted during the application development life cycle. The Biden administration has gone so far as to issue an executive order requiring all agencies to provide SBOMs for all the commercial and custom software they use, but as of yet a deadline for compliance with that order hasn’t been set.

    In general, the Linux Foundation survey found that a large percentage of respondents (82%) are already familiar with the term SBOM. Respondents cited various benefits of having an SBOM, including making it easier for developers to understand dependencies across components in an application (51%), making it easier to monitor components for vulnerabilities (49%) and making it easier to manage license compliance (44%).

    However, the survey also makes it clear there is much SBOM work to be done. A full 62% of respondents, for example, are looking for better industry consensus on how to integrate the production/consumption of SBOMs into their DevOps practices. Respondents also cited a need for consensus on the integration of SBOMs into their risk and compliance processes (58%).

    More than half (53%) also said there is a need for better industry consensus concerning how SBOMs will evolve and improve.

    The survey also makes it apparent that organizations are more aware of the role SBOMs play in securing supply chains. A full 80% of organizations are aware of the White House’s executive order on improving cybersecurity, with more than three quarters (76%) considering making changes as a direct consequence of the order. Overall, the survey found the top consideration organizations focus on when evaluating open source software is security.

    Stephen Hendrick, vice president of research at the Linux Foundation, said 2022 is likely to be remembered as the year of the SBOM. There are several standards for building SBOMs, including an open source software package data exchange (SPDX) specification backed by The Linux Foundation and the Joint Development Foundation that is now recognized as the ISO/IEC 5962:2021 international standard. There is also CycloneDX, a lightweight SBOM standard based on an open source project that originated via the Open Web Application Security Project (OWASP) community and a software identification (SWID) standard for tags that some organizations use to create SBOMs.

    SBOMs are, essentially, a tool for listing the components that make up an application and are used inconsistently. However, when a critical vulnerability is discovered, they can sharply reduce the amount of time required to discover all the software components that need to be remediated. The challenge is, with the rise of containers, it has become much simpler to rip and replace software components in a way that may not always be reflected in the SBOM. Hendrick said in time, advances in technologies such as machine learning algorithms should make it easier to instantly reflect those changes in an SBOM.

    Regardless of approach, it’s apparent DevOps teams, like it or not, are about to be held more accountable for the provenance of every component employed across their entire application portfolio.

  • Continuous Security: The Next Evolution of CI/CD

    Continuous Security: The Next Evolution of CI/CD

    Following a wave of high-profile cyberattacks and the White House’s release of the executive order on improving the nation’s cybersecurity, how to build a successful cybersecurity program has never been so hotly debated as it is now. From SolarWinds to the Colonial Pipeline attacks, these events demonstrate that defensive measures alone cannot mitigate cybersecurity risk, and any cybersecurity program must begin where nine out of 10 breaches begin—the code. 

    The adoption of CI/CD in recent years as an extension of Agile and DevOps has enabled organizations to embrace digital transformation and ensure code is always being delivered that matches the most current business needs. Unfortunately, this has further siloed security as processes failed to keep pace. While there are a number of point solutions to address the ever-expanding domain that encompasses application security—from traditional pentesting and vulnerability scanners to monitoring of the individual components of the DevOps toolchain like containers—too many tools results in a DevSecOps “hairball” that leaves organizations inundated with data, yet without actionable information. 

    Moving Beyond Secure DevOps

    As organizations continue to evolve their delivery processes, security has found its role in secure DevOps (SecDevOps) programs to ensure the execution of security processes at every step of the software development life cycle (SLDC). By continually managing security practices, policies and debt in existing pipelines, this approach ensures that all stakeholders—from the C-suite to the developers and AppSec managers—have the information they need at every step of development to share responsibility in delivering secure software.

    However, these programs, while a good starting point, have left security requirements and checks in PDFs, Excel documents, and emails failing to capture the same benefits of security integration into the SDLC that Dev and Ops have commanded. Without SecDevOps orchestration, the information often lags the pipeline, creating new bottlenecks and uncertainty. SecDevOps orchestration gives security and development teams the confidence to know they’re following the right policies and eliminates the manual work that creates drag on the SDLC. With the automation of the application security process, enterprises get consistency and insight into their program that allows their focus to stay on shipping code while knowing it meets their organizational security standards. 

    Adding Continuous Security

    With CI/CD, organizations are able to rapidly meet the most current needs of the business as they rapidly evolve, but without a continuous approach to security as well, once again, security is siloed off. Organizations must be able to adapt their security requirements for changes both internal (changing databases, different software versions, etc.) and external (compliance requirements, changing threat landscape, etc). We need to take CI/CD one step further and also have security integrated continuously. 

    By extension, continuous security (CI/CD/CS) is the philosophy of continuously shipping software that meets the most current security standards for the business, accounting for internal and external change throughout the SDLC. 

    To effectively adopt a CI/CD/CS, organizations must focus on three key principles:

    • There is no perfect code, therefore there is no perfect security—Good application security manages cyber risk in line with overall business strategy. When you have the ability to accept risk within the risk tolerance of the businesses, you know the right times to stop, and the right times to carry on because other controls are in place. Don’t let perfection be the enemy of the shipped. 
    • Bite-sized application security—DevOps isn’t about moving fast and breaking things, it’s about moving efficiently and fixing things at the right time. Deliver the right application security information at the right time to the stakeholder responsible for executing it. This ensures better collaboration so stakeholders know where, when and with whom to direct their attention. 
    • Micro-feedback loops—Leverage orchestration to get real-time feedback on policy compliance before it creates bottlenecks down the line. This enables you to respond to changes both internal and external as quickly as possible, creating an iterative cycle of information for future decision-making. 

    By continually managing security practices, policies, and debt in existing CI/CD pipelines, this approach allows a scalable application security program to be deployed in any SDLC so it can continually evolve to always be in lockstep with today’s business.  

    Different organizations have different risks they need to account for, which means security must be aligned to business strategies and priorities in order to dynamically respond. With end-to-end integration in the SDLC, continuous security supports CI/CD to improve productivity and speed time-to-market, while reducing the risks that might impact a particular business. Software is inherently impermanent and organizations need to be able to continuously balance security, technical and business priorities to ensure they are maintaining their focus on what matters most: Delivering value to customers and shareholders. 

  • GrammaTech Adds SBOM Analysis Capability to CodeSentry

    GrammaTech Adds SBOM Analysis Capability to CodeSentry

    GrammaTech today updated its CodeSentry code inspection platform to include the ability to create a software bill of materials (SBOM) by analyzing application binaries.

    Walter Capitani, director of technical product management for GrammaTech, said version 3.0 of CodeSentry leverages the algorithms the company uses for binary software composition analysis to enable organizations to better address software supply chain concerns in the wake of a series of high-profile vulnerabilities.

    The tool can be applied to both commercial software and open source components via integration with Risk Based Security’s VulnDB database, created to track security issues.

    GrammaTech

    There is more focus than ever on creating SBOMs in the wake of the Biden administration’s recent executive order that will require federal agencies to only use software that comes with an SBOM. However, most organizations are not provided with access to the source code used within the applications they employ. GrammaTech enables organizations to address that issue by analyzing the binary code within an application to generate an SBOM.

    That report not only identifies all the components in an application, it also lists all known vulnerabilities associated with the version of the components being employed, said Capitani. CodeSentry will also list other common software products and the versions that may be impacted by the same vulnerabilities, along with versions of the software that have remediated the issue or versions of a component that have not been impacted by those vulnerabilities.

    Almost all software applications include third-party and open source components that create blind spots within software supply chains. In fact, that issue is what makes remediating zero-day application vulnerabilities so challenging; especially when they are discovered in, for example, a log management tool like Log4j that is widely used in Java applications.

    GrammaTech is making a case for a binary software composition analysis (SCA) tool that enables DevOps teams to address vulnerability issues prior to an application being deployed in a production environment. At the same time, however, security and compliance teams can now use the same tool to determine the level of risk an organization might be incurring once an application is deployed in production. That latter capability is especially critical because zero-day vulnerabilities are often not discovered until long after an application is deployed in a production environment, noted Capitani.

    Regardless of approach, the need to better secure software supply chains is now a major IT issue that should ultimately encourage more organizations to adopt DevSecOps best practices to better secure applications. The challenge, of course, is not just espousing the need for those practices but also providing developers with tools they will actually use to implement those practices. The success or failure of those efforts comes down to not just the efficacy of the tool but also how well it fits within the overall developer experience. After all, the greatest tool in the world will still languish if it’s too difficult for the average developer to employ.

  • Securing the Software Supply Chain with Behavioral Analysis

    Securing the Software Supply Chain with Behavioral Analysis

    Lately, software supply chains find themselves in a very interesting and uncomfortable position—the industry spotlight—and not in a good way. While significant and costly breaches such as  SolarWinds or Kaseya make front-page news, supply chain attack tactics (e.g. typosquatting or dependency confusion) that target package managers such as npm, PyPI or WinGet can poison downstream applications or compromise developer credentials.  

    The software engineering community has been steadily increasing its use of third-party and open source solutions to help create new offerings. In fact, over the last five years, there has been a 259% increase in the use of open source.

    One reason for this is the simple fact that creating new applications takes time and can strain budgets that are already tight. With open source code, software engineers gain fast access to pre-existing code that’s already demonstrated a proven ability to address the very unique challenge they are looking to solve. By removing the need to reinvent the wheel, the development timeframe is accelerated, the costs are lowered and teams are freed to focus on the creation of new and unique features that the customers demand.

    At this point, turning to third-party code may seem like a no-brainer. However, it can also open the door to potential risks. This is especially true with engineers who, rather than checking software to ensure it is secure and compliant, take the providers’ assurances as gospel. 

    They are not alone. Other groups will try to conduct their initial due diligence at the onset if that’s possible. Soon after they then ease into a “set it and forget it” approach, where they fail to update the code over time. As a result, while the code may appear secure initially, vulnerabilities can emerge over time, and if the software is not continually updated, bad actors can leverage an unprotected window of opportunity. In fact, according to Enterprise Security Group’s “Modern Application Development Security” eBook, 48% of organizations regularly push vulnerable code. The same research also found that 60 percent of organizations have had production application vulnerabilities exploited.

    Organizations conduct static application security testing (SAST) and dynamic application security testing (DAST) to assess pre-production code vulnerabilities. They will also scan with AV before releasing software, examine signing certificates, and code quality. Yet, despite these efforts, they remain challenged by gaps in security processes and the ability to sufficiently inspect large, complex and multi-layered software packages. What’s missing is the ability to conduct in-depth analysis to pinpoint behavioral differences between compiled software versions.  

    Malicious tampering can often involve changing how the software interacts with the system on which it is deployed.  Differential behavior analysis highlighted below makes it easier to detect those unusual changes. For example, having an application suddenly add a pre-install script that downloads files via certutil is highly unusual. If the addition was planned, reasons for the change would be well documented and it would be associated with a significant new feature. For this type of change to happen in any other scenario is suspicious and deserves further investigation before the software is released. In this case, such action would have caught ua-parser-js developer’s account compromise.

    supply chain

    With the software supply chain at risk and with shared code the new normal, what’s needed is software assurance. 

    Software assurance allows teams to inspect every application layer within an installation package for the presence of software tampering, malware and other indicators of software supply chain attacks.   

    Begin the software assurance process with the deep inspection step through recursive package decomposition. The resulting software bill of materials (SBOM) becomes so much more than a build manifest (a list of components that should be in the final build). It becomes the means to determine exactly which components have unacceptable build quality or those that contain unwanted software behaviors. This enables developers to verify the code they are working with and take appropriate action to protect their customers and partners from the majority of software risks. These assessments include:

    • Software grading: The software package and every included component can be graded based on the types and severity of security issues found. Using a grading system makes it easy for software buyers to gauge the level of risk posed by a software package and determine whether additional deployment measures can be taken to mitigate those risks. For developers, component grading makes it easier to prioritize their remediation efforts and aids in the selection of higher-quality third-party components.  
    • Application hardening: Activating specific build or compiler options can mitigate vulnerabilities and protect applications against attack—but only if they are implemented correctly. Assessing whether these mitigations are correctly implemented ensures that these protection mechanisms will work as expected. 
    • Binary behavior analysis: This allows teams to fully understand how each software component interacts with the system on which it will run. The ability to understand third-party component behaviors, even when developers have no access to the source code, delivers a more comprehensive understanding of supply chain risks. Checking for unusual software behaviors or unexpected behavioral changes between one version and the next is often the only way to identify software tampering by a malicious actor. The ability to have this final check before distribution enables software developers to validate that the software being released is trustworthy.

    For companies that are using software to create business value or producing software that is mission-critical for their customers, turning a blind eye or making software assurance assumptions can no longer be tolerated. In today’s climate where increasingly sophisticated threats loom, inspecting software and monitoring updates for signs of tampering, malicious or unwanted additions is essential and must become a part of standard software development practice. 

  • WhiteSource Adds SBOM Tool That Lists Vulnerabilities

    WhiteSource Adds SBOM Tool That Lists Vulnerabilities

    WhiteSource has added a software bill of materials (SBOM) tool to its portfolio that, in addition to capturing the components of an application, also surfaces vulnerabilities that should be addressed.

    Many organizations are becoming more rigorous about making sure SBOM are attached to every software development initiative in the wake of an executive order issued by the Biden administration that requires federal agencies to employ them. While not every organization builds applications for federal agencies, the fact that the federal government is requiring them in the wake of a series of high-profile breaches has led other organizations to review their software supply chain processes.

    An SBOM facilitates those reviews by making available a formal, machine-readable inventory of software components and dependencies that can be used to track their supply chain relationships and identify dependencies and hierarchical relationships.

    Ori Bach, executive vice president for product at WhiteSource, said WhiteSource SBOM takes the concept a step further by also identifying open source libraries. It will also automatically update the SBOM when changes are made to make it easier to identify unintentional or malicious content being installed during application builds.

    Finally, WhiteSource SBOM also provides remediation guidance that ensures updates won’t break the build.

    Bach said it’s already apparent cybercriminals have significantly increased their effort to compromise supply chains as part of an effort to compromise as many downstream applications as possible. In many cases, cybercriminals are now specifically targeting open source projects that create software that tends to be employed across a wide range of use cases.

    An SBOM in and of itself doesn’t make applications more secure. However, it can provide visibility into the components of an application that can then be used to inform DevSecOps best practices, which organizations are implementing more broadly as responsibility for application security continues to shift left toward developers.

    There are two primary specifications that organizations can use to create an SBOM. The Software Package Data Exchange (SPDX) specification is an open standard for communicating SBOM information including components, licenses, copyrights, and security references. Defined by the Linux Foundation, SPDX is now recognized as the ISO/IEC 5962:2021 international standard. The second is the Software Identification (SWID) format that is today widely used by publishers of commercial software.

    Regardless of the format used to construct the SBOM, Bach said there’s an opportunity to more closely align the increased visibility it enables with the application security goals of the organization building the application.

    The primary reason SBOMs are not as widely used as they might be by now has as much to do with inertia as it does with technology. However, as organizations start to expect an SBOM to be made available, it’s clear application developers and builders will need to find a way to automate the SBOM process as applications are continuously updated. The challenge, of course, is that applications are now being updated with greater frequency—thanks mainly to widespread adoption of DevOps best practices—that now need to be integrated with any tool for creating and maintaining an SBOM.

  • Welcome to the New Field of Software Supply Chain Management

    Welcome to the New Field of Software Supply Chain Management

    Supply chain management is the newest ‘shiny object’ in both the DevOps and DevSecOps communities. But what does it mean in relation to software development?

    Historically, supply chain management is a commerce term that refers to tracking the logistics of goods and services moving between producer and consumer. This would include the storage and flow of raw materials with a focus on the channels that support the process.

    When we look at this concept from the perspective of software development, we will soon see that it is a new form of software configuration management. Yes, the new SCM is … SCM. The core of supply chain management is the process of controlling changes in software. The new SCM expands those old practices to include all ‘raw materials’ which we manage as part of our software build and package steps. For instance, when companies purchase and download open source libraries used in their in-house software. Supply chain management includes the interrogation of these ‘raw materials’ as well as all of the internal code and libraries. We will soon be hearing more about software bill of materials (SBOM) reports and difference reports, as they are critical for understanding the objects that flow through the software we create.

    The software supply chain or software configuration management practice hasn’t been talked about much until recently. This area of expertise has never been ‘sexy.’ That is, until the SolarWinds supply chain hack. The SolarWinds hack was a hard lesson to learn, but it taught us to take a closer look at how we consume our raw materials and to be more serious about how we build and package our software.

    According to FireEye, the firm that discovered the backdoor supply chain hack:

    “SolarWinds.Orion.Core.BusinessLayer.dll is a SolarWinds digitally-signed component of the Orion software framework that contains a backdoor that communicates via HTTP to third-party servers. We are tracking the Trojanized version of this SolarWinds Orion plug-in as SUNBURST.”

    It was obvious, something went very wrong with the creation of that .dll. I don’t pretend to fully understand how this breach occurred. But I do understand the build process and have been talking about the potential for these types of breaches for over 25 years.

    There have always been big security gaps and vulnerabilities in our most basic software development practice—the compile/link process. Most build processes are imperatively defined using an Ant, Make or Maven script. Each time the build runs, it rebuilds all the binaries, even if the corresponding source code has not changed.

    This is a problem. Instead, we need a build that is incremental. Incremental builds are difficult to script because they need more advanced logic. Most developers are not given adequate time to create a better build process, one that only rebuilds the changes. This means it is next to impossible to audit why a binary was recompiled because they are always recompiled. If we only recompiled the binaries that had corresponding code updates, we could more carefully audit the code and make sure that only approved coding updates were included.

    This may not have caused the SolarWinds attack, but it could have. Once hackers have gotten past the firewall they can find the build directory, read through the build scripts and identify the perfect piece of code to update with their bad function. The next time the build runs, a ‘clean all’ recompiles everything and, like dark magic, a SUNBURST is created.

    In our not-too-distant past, the developer community had tools that controlled software builds beyond what an imperative script could do. OpenMake Software, for example, provided a build automation solution called Meister that ensured that incremental builds were easy. As part of the build, it generated SBOM reports and differences reports allowing teams to easily audit and compare the actual source changes to confirm that only approved code updates were included. Another example was Rational Software’s ClearCase which used a program called ClearMake. ClearMake used a process called ‘winkin’ to reuse ‘derived’ objects that had not changed. This process created an incremental build that could be easily audited.

    I realize that I am simplifying the overall problem, but it is a good example of the basic supply chain best practices and how potentially vulnerable our processes are.

    The time to carefully think about how we manage our raw materials and overall supply chain is now. I’m guessing that most monolithic practices will not change much; it is too costly and impactful to rewrite hundreds of CI pipelines. But that does not mean we can’t solve the supply chain puzzle as we shift into cloud-native development in a microservice architecture.

    In a microservices architecture, we need to begin thinking about what the supply chain looks like. How do we track raw materials that are in the form of hundreds of small ‘bounded context’ functions? The good news is there is an emerging microservice catalog market that can become part of the supply chain solution. A microservices catalog can track versions of services to versions of their consuming applications. Your new SBOM report will have two levels: First, an SBOM for the microservice. Second, aggregated data at an application level. Remember, in this new architecture a full build is not done.

    It’s important to understand that microservices are naturally incremental and are independently built, packaged and deployed. Managing these small services opens the door to more closely auditing their source code before they are released.

    As we shift from monolithic development to microservices, we have an opportunity to incorporate supply chain and configuration management best practices. This includes being able to carefully audit the code before a release is done. And remember, we must do this as fast as possible. It sounds like a big task, but it’s well worth the effort. Collectively, we will find the answers as we explore new ways to manage our DevOps pipeline and incorporate configuration management and DevSecOps principles.

  • How Third-Party Security Assurance Enhances DevSecOps

    How Third-Party Security Assurance Enhances DevSecOps

    Enterprises are constantly trying to do more with less today, and do it faster to gain competitive advantages and grow revenue. Nowhere is this more prevalent than in their internal software development processes. The movement to third-party or external sources of code is a natural reaction to “faster” release cycles. However, this need for speed can have unintended downstream security consequences for application development teams.

    As cybercrime has grown parallel to the explosion of digital processes in many enterprises, “security by design” needs to go from a nice-to-have concept to a hard reality. This is the reason DevSecOps has gone from buzzword to practice for many development teams. Implementing a software security assurance program, which embeds security as part of the coding and assembly process rather than a separate, after-the-fact quality testing function performed by security staff, is vital to limiting the cost of fixing vulnerabilities and preventing data breaches.

    Software Attacks are a Growing Problem

    One of the recent and most high-profile cybercrime incidents involved hackers using the SolarWinds software platform as a launching pad to breach companies. With threats specifically targeting software on a growth curve, organizations need to secure both the software they develop and that which they acquire from suppliers. This often includes a lot of reused code picked up from vendors and open source libraries that offer the building blocks for software and applications to help developers work faster and cheaper—but with a potential security cost.

    Maintaining software security has become more complicated as enterprises rely more on third parties for the components to develop software faster and cheaper and keep up with digital disruption. The share of code developed in-house for enterprise software has dropped from 43% to 38% in the last five years, while the use of commercial and open source software has grown in its place. Rather than rely on custom code, many developers are leveraging open source components or API libraries to build applications. Some software vendors provide application libraries that can have third-party components purchased by that vendor for their customers.

    Leaning on third-party code can leave software open to abuse, as developers have less visibility into the content of the components they use as the building blocks of their programming. Some vendor libraries get reused by the vendor for different applications, and some use open source components in their code; a developer may be using third- and fourth-party code from who-knows-what source. Vulnerabilities can be hiding many layers deep in the code, and unless developers know the source, they are difficult to detect.

    This is where a well-established software security assurance program can reduce the risk of cybersecurity incidents and the impact of security weaknesses. It protects users and the enterprise by establishing cybersecurity practices, fulfills the organization’s risk management and compliance requirements and offers the C-suite visibility into the process.

    A Checklist for Software Security Assurance

    A well-organized security assurance program ensures that security requirements have been established for the software and the software development process and that any software deployed is free from vulnerabilities. If any are found, it also establishes remediation steps to handle them.

    Some important practices:

    ● Trust but verify: Ensure that a security evaluation has been performed for the software throughout the software development life cycle (SDLC). Proactively validate the security and integrity of software code and provide results identifying any vulnerabilities found and assign remediation steps to correct them before release into production.
    ● Know what’s in the software: Since many developers and software vendors rely on open source and third-party code more frequently, it’s more important than ever to know what those components are and where they come from. Software security
    assurance should include the software bill of materials (SBOM) for any open source code and third-party components.
    ● Put it in writing: Produce documented proof, such as the SBOM mentioned above, and generate a vulnerability report proving the integrity of the software. If vulnerabilities are found, determine the cybersecurity risk and the potential impact based on the Common Vulnerability Scoring System (CVSS) score, an industry standard, to guide remediation.

    A good software security assurance program makes sure that each software review or audit includes an evaluation of the security requirements for the enterprise. These can vary by industry—and even within the organization—based on which function the software is running. A program running mailing lists for a power generation company is not as mission-critical as the software running the power grid.

    With all industries in the crosshairs of cyberattackers, an effective and diligent software security assurance program will make it harder for them to find a back door and can help keep your organization safe.