Tag: supply chain security

  • npm is Scam-Spam Cesspool ¦ Google in Microsoft Antitrust Thrust

    npm is Scam-Spam Cesspool ¦ Google in Microsoft Antitrust Thrust

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: The npm registry suffers spam infestation, and Microsoft makes Google sad. (more…)

  • Awareness of Software Supply Chain Security Issues Improves

    Awareness of Software Supply Chain Security Issues Improves

    A global survey of 167 software professionals suggested that, while there is a lot more awareness of application security issues, the adoption of DevSecOps best practices is still not pervasive.

    The survey, conducted by Chainguard, the Eclipse Foundation, the Rust Foundation and the Open Source Security Foundation (OpenSSF), found that just over half (51%) of respondents are either concerned or are extremely concerned about software supply chain security.

    In addition, only a third of respondents (33%) reported they are familiar with the Supply-chain Levels for Software Artifacts (SLSA) framework for building more secure applications. Well over a third (36%), however, said they had never heard of it.

    Only a quarter of respondents (25%) reported that their team always signed built artifacts, the survey found.

    The survey identified the most challenging issues developers are encountering and found they are reproducing builds (64%) followed by creating hermetic builds that are isolated from other software libraries (62%).

    Mikaël Barbero, head of cybersecurity for the Eclipse Foundation, said while awareness of software supply chain issues is higher, it’s apparent that other priorities are still getting in the way of adoption of DevSecOps best practices. For example, software bills of materials (SBOMs) may generate a lot of headlines, but their adoption remains mixed, he added.

    John Speed Meyers, a security data scientist for Chainguard, noted that incentives still need to change; too many managers that hire developers still emphasize performance and delivery times over application security. Many developers, as a result, still tend to view cybersecurity as an obstacle to be overcome or worked around rather than a core capability that they will be graded on, he added.

    In theory, as responsibility for application security shifts left toward developers, overall cybersecurity will improve. Most developers, however, have little to no cybersecurity training, so the odds they will be able to resolve these issues are low. Instead, many organizations are either trying to embed cybersecurity professionals within DevOps workflows or, at the very least, deputize at least one developer to advocate for cybersecurity within those teams.

    Regardless of commitment level, it’s apparent that organizations need to address everything from locking down developer environments to thwart phishing attacks to ensuring application builds are not inadvertently infected with malware. The challenge organizations face is both technical and cultural, so the amount of effort required should not be underestimated.

    In the meantime, organizations should expect to see cybercriminals increase their attempts to compromise software supply chains. Infecting malware into software components that will be used by multiple downstream applications is, from their perspective, one of the most efficient means of wreaking havoc. Right now, organizations make it too easy for cybercriminals to compromise application environments.

    Organizations should also recognize that tolerance for insecure applications is also declining, as evidenced by the National Cybersecurity Strategy put forward by the Biden administration. It’s not so much a question of whether organizations that create software will be held liable for application security issues as much as it is to what degree.

  • Dev of core-js Will Flip Table ¦ Another 451 PyPI Maldeps

    Dev of core-js Will Flip Table ¦ Another 451 PyPI Maldeps

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Denis Pushkarev is fed up with core-js freeloaders, and hundreds more malicious packages found at PyPI. (more…)

  • Software Supply Chain Security Debt is Increasing: Here’s How To Pay It Off

    Software Supply Chain Security Debt is Increasing: Here’s How To Pay It Off

    Last year, the world woke up to the software supply chain dilemma. We saw a spike in attacks as hackers sought to exploit known and unknown vulnerabilities within dependencies. There is also the chance of typosquatting, and malicious code commits to consider. Such supply chain attacks have increased by a shocking 742% over the past few years.

    It’s easy to let software security debt accumulate, as it’s cumbersome to stay on top of frequent updates — especially when new releases cause breaking change. Furthermore, companies might unknowingly collect security debt by hastily looping in projects whose origin is unknown. Plugging these gaps can bring a high burden down the road, which too often falls on the shoulders of developers to manage.

    I recently reconnected with Dan Lorenc, founder and CEO of Chainguard, to discover why risks in the software supply chain contribute to increased security debt and how organizations can proverbially pay it off. Lorenc is a key figure behind Sigstore, the open source utility built to verify the provenance of open source packages. Below, we’ll consider the state of software supply chain security and examine some modern solutions that lessen its severity.

    Why is Supply Chain Security Debt Rising?

    Modern software ecosystems are an intricate mosaic of dependencies, and supply chain security concerns often arise at the cracks between them. “It’s about the gaps and hand-off points between individuals in the software life cycle,” said Lorenc. Since these hand-off points can threaten systems at large, they can accumulate considerable security debt if left unguarded.

    Another reason why security debt is increasing, said Lorenc, is that fixing issues is rarely incentivized—it’s always thought of as “someone else’s problem.” Minimizing this debt will require organizations to change this mindset and follow modern security best practices, like implementing multifactor authentication infrastructure and more frequent code reviews. It will also take a coordinated effort from package managers to integrate tooling that helps verify the legitimacy of packages, said Lorenc.

    Solutions to Reduce Software Supply Chain Security Debt

    Automated Vulnerability Scanning

    In addition to advancing internal culture toward greater security awareness, organizations will benefit from automation that enhances the discovery of vulnerabilities. Because when a severe incident like Log4j hits the presses, it’s a mad scramble to respond. Even a year later, one in four downloads still possesses the infamous vulnerability.

    Integrating automated security scanning is the first step to knowing how these incidents impact your security posture. A tool like Snyk can do a great job of surfacing known vulnerabilities and finding where they lie within your software stack and provide remediation advice. Continually checking for updates can also help pay off security debt “as you go” instead of upgrading everything all at once, says Lorenc. But although scanning tools are essential for increasing visibility, they don’t address the root cause of why they are vulnerabilities in these packages in the first place, says Lorenc.

    Checking Transitive Dependencies

    Reports find that 95% of vulnerabilities stem from transitive dependencies. These are dependencies that are buried deep within the dependency tree of another package. And depending on the programming language, they’re not always that visible. The combinatory effect of transitive dependencies can lead to exponentially more vulnerabilities and issues if not carefully tracked. And since they’re running locally with the same privileges as your other packages, you shouldn’t treat these vulnerabilities any differently, said Lorenc. “You need to realize they can affect your application in the same way.”

    Validating The Source

    The link between the package manager and the source code is a frail area that warrants additional verification. Social engineering tricks can effectively trick users into downloading insecure packages that appear safe at the outset yet hide corrupt code. Or, account takeovers can result in attackers inserting malicious code into commonly used open libraries. Package managers often host built versions and forked versions of software produced by the community on GitHub, yet do not validate a clear link to the original repository. This gap heightens the chance for a malicious package to slip through the cracks, says Lorenc.

    This is something that Sigstore, the open standard for signing, verifying and protecting software, aims to accomplish. In mid-2022, Sigstore was implemented within Kubernetes, signaling the adoption of Sigstore as a standard throughout the open source ecosystem. It’s also been adopted by Npm and PyPI and Maven Central will soon support Sigstore as well, said Lorenc. Although some of these moves have received pushback from developers, Lorenc argued that such verification is necessary to help link packages to their source and increase credibility for open source dependencies.

    Chipping Away At Security Debt

    Like technical debt piles up over time, security debt can quickly rise if left unchecked. Chipping away at increasing software supply chain security debt will likely require a “pay as you go” approach wherein developers continuously scan and update their dependencies. One good sign is that people are paying more attention to risks latent within their code, and the industry is discovering and sharing more potential vulnerabilities before they are exploited.

    “Security has advanced, and there are common best practices across the industry,” said Lorenc. But if these practices aren’t followed, it could bring dire consequences for the organizations and the industry as a whole. And although Sigstore can help bridge the disconnect between the package managers and the source code, there are plenty of other techniques to help improve a security footprint for open source software and cloud-native infrastructure. For example, SLSA and greater use of SBOMs can help address security debt more holistically.

    The software supply chain security dilemma is an advanced topic that requires a coordinated effort from various stakeholders to remedy. The important takeaway is to stay positive, see the debt, and pay it off incrementally, says Lorenc.

  • Secure Software Summit: Exploring Secure Coding Best Practices

    Secure Software Summit: Exploring Secure Coding Best Practices

    In an era where software is dominating the world, the security and quality of code must remain a high priority. Delivering secure and reliable software at a rapid pace is crucial for most organizations today, but it’s not an easy task. What security best practices do organizations put in place to successfully produce secure software? How should DevOps teams incorporate updated security practices and tools throughout the software development lifecycle? At Secure Software Summit, taking place Jan. 27 at 9 a.m. PT, the world’s leading cybersecurity experts will come together to share and teach the latest methods and breakthroughs on secure coding and deployment practices.

    The virtual event features thought-provoking discussions, networking opportunities and educational sessions focused on:

    • Open source supply chain security
    • DevSecOps
    • Shifting security left
    • Security Chaos Engineering (SCE)
    • Security and compliance
    • Security metrics
    • Zero trust

    Secure Software features an outstanding lineup of innovators, practitioners and academics of secure software development, including:

    • Aaron Rinehart, co-founder and CTO at Verica
    • Dan Lorenc, founder and CEO at Chainguard, Inc.
    • Shinesa Cambric, principal program manager, Identity Signals and Protection Team at Microsoft
    • Vickie Li, developer evangelist at ShiftLeft
    • Fabian Yamaguchi, chief scientist at ShiftLeft
    • Jonathan Schneider, co-founder and CEO at Moderne, Inc.
    • Abhishek Arya, principal engineer and manager, Google Open Source Security Team at Google
    • Steve Springett, senior manager of product security at ServiceNow and chair of the OWASP CycloneDX Core Working Group
    • Jasmine Jackson, senior application security engineer at Disney
    • Suchakra Sharma, staff scientist at ShiftLeft
    • Harini Rangarajan, engineering manager, product security at Twilio
    • Mark Wireman, senior manager at Accenture
    • Shannon Lietz, vice president of Vulnerability Labs at Adobe
    • Vandana Verma, security relations leader at Snyk
    • Yash, head of security at Sendbird
    • Chetan Conikee, CTO at ShiftLeft
    • James Chiappetta, SVP of cybersecurity at Blackstone

    Attendees will have access to valuable resources available for download and will also receive a link to access the virtual environment on-demand. To see the full agenda and to register, please visit the Secure Software Summit website.

  • 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.

  • Oxeye Platform Helps Fix Code Vulnerabilities

    Oxeye Platform Helps Fix Code Vulnerabilities

    Fresh from raising $5.3 million in seed funding, Oxeye emerged this week from stealth to launch a namesake application security testing platform that, in addition to pinpointing issues in code, also provides advice to best remediate the issues it found.

    The Oxeye platform requires developers to download an observer tool that scans code for vulnerabilities. Once pinpointed, the Oxeye platform guides developers through the remediation process without requiring them to inject agent software into every application.

    Oxeye CEO Dean Agron noted developers don’t typically have a lot of cybersecurity expertise. As application environments become more complex—thanks to the rise of microservices-based applications—it only becomes more likely that mistakes will be made. The only way to resolve security issues before applications are deployed in a production environment is to augment developers using a platform that finds vulnerabilities all the way down to specific lines of code, he said.

    In theory, responsibility for application security is being pushed further left toward developers as organizations embrace DevSecOps best practices. However, making developers more accountable for security without providing them the tools required to achieve that goal is not going to improve the overall state of application security.

    The challenge organizations face today is finding a way to empower developers to address security issues without slowing down the rate at which applications are built and deployed. The best way to achieve that goal is to give developers access to a security tool designed to both analyze code for vulnerabilities and explain how to avoid encountering that issue again, said Agron.

    Left unaddressed, the current software supply chain crises will only deepen, added Agron. According to International Data Corp. (IDC), more than 500 million digital applications and services will be developed and deployed using cloud-native platforms by 2023. That’s roughly equal to the total number of applications and services deployed over the last 40 years, according to IDC.

    It’s not clear to what degree the rise of digital applications might force the DevSecOps issue within more organizations. It’s is clear that a new generation of more complex applications based on microservices is being rolled out to drive a wide range of mission-critical applications. The more business value an application has the more attention it inevitably attracts from cybercriminals.

    Regardless of the type of application, it’s apparent that there is a pressing need for a way to better secure applications. The further left that process starts the less costly it becomes to achieve and maintain security. Cybersecurity teams have a vested interest in helping developers do the right security thing as early as possible if no other reason than to reduce the number of vulnerabilities they will inevitably discover later.

    Making developers more aware of security issues is, of course, only the first step. However, in the absence of any tools that can be easily incorporated within an application development workflow, the concerns being raised will amount to little more than yet another sermon that will be ignored as developers once again rush to meet yet another application delivery deadline.

  • CloudBees Acquires Neuralprints to Shift Compliance Left

    CloudBees Acquires Neuralprints to Shift Compliance Left

    At the online DevOps World 2021 conference today, CloudBees revealed it has acquired Neuralprints to provide the core technology for CloudBees Compliance, a real-time compliance and risk analysis platform that it will roll out in the first quarter of 2022.

    At the same time, CloudBees has enhanced the feature management capabilities of its namesake continuous integration/continuous delivery (CI/CD) platform to provide greater visibility into and control over feature flags that are now widely used to add new capabilities to applications.

    Prakash Sethuraman, chief information security officer (CISO) for CloudBees, said CloudBees Compliance will make it possible for DevOps teams to continuously enforce compliance policies as part of an effort to better secure their software supply chains. Those DevOps teams will be able to enforce compliance across code, binary artifacts, data, identity and infrastructure environments in a way that provides developers and IT operations teams with instant actionable feedback to enable issues to be addressed long before an application is deployed in a production environment.

    CloudBees Compliance is based on a mix of open source and proprietary technologies developed by Neuralprints and will be made available for on-premises IT environments as well as via a software-as-a-service (SaaS) application. The goal is to enable organizations to manage compliance as code as part of any effort to shift more responsibility for application security further left toward DevOps teams, said Sethuraman.

    CloudBees Compliance

    A survey of 500 C-level executives published today found nearly half (45%) admit that initiatives to secure their software supply chains are halfway or less-than-halfway complete. Nevertheless, 95% claimed their software supply chains are secure (95%), with more than half (55%) posting they are very secure.

    A full 93% said they are prepared to deal with an issue such as ransomware or a cyberattack on their supply chain. However, nearly two-thirds (64%) admitted they are not sure who they would turn to first if their supply chain was attacked; with 58% admitting that, if they experienced an attack, they have no idea what their company would do. An equal percentage (64%) said it would take more than four days to fix the problem if they did experience an issue.

    Almost all C-level executives (95%) said they think more about securing the supply chain now than they did just two years ago, and 92% said a security issue would impact their brand. A total of 83% said security issues cause their developers to drop everything to review code, with 82% noting that caused the organization to spend less time on innovation.

    On the plus side, 95% of executives said container images are checked for high or critical vulnerabilities, while an equal number said automation access keys are set to expire automatically. A total of 92% said their company only accepts commits signed with a developer GPG key, while 90% said dependencies to trusted registries are limited at their organization, while 89% said administrative access to CI/CD tools is restricted (89%).

    Of course, what C-level executives believe and what actually occurs inside an organization are not always one and the same. A series of high-profile software supply chain breaches resulted in a number of organizations reviewing their software supply chains. At the same time, the Biden administration has issued an executive order requiring all federal agencies to conduct similar reviews.

    One way or another, most organizations will soon find themselves embracing a wider range of DevSecOps best practices to ensure the integrity of software supply chains no matter how secure they may think their software development platforms are today.