devopsy.kinsta.cloud

Tag: Software Supply Chain Security

  • Endor Labs Applies Graph Analysis to Secure Software Supply Chains

    Endor Labs Applies Graph Analysis to Secure Software Supply Chains

    Endor Labs exited stealth mode today to launch a platform that applies graph analysis to identify the depth of dependencies that exist within an application.

    Fresh from raising $25 million in funding, Endor Labs CEO Varun Badhwar said the Dependency Lifecycle Management Platform makes it simpler for organizations to manage dependencies within applications that can involve tens of thousands of components.

    Existing software composition analysis (SCA) tools are not able to as accurately identify the dependencies between software components because they generate too many false positives, he added.

    To address that problem, the Dependency Lifecycle Management Platform provides the equivalent of a credit risk score for each component employed with an application environment, said Badhwar.

    Designed to run out-of-band within a continuous integration process, the Dependency Lifecycle Management Platform is currently being made available via a private beta program.

    On average, bout 80% of an application is made up of open source components that developers downloaded from a repository. The challenge is that many of those components have known vulnerabilities. The Dependency Lifecycle Management Platform makes it simpler to both identify those vulnerabilities during the build process and find components that might be impacted by a newly discovered zero-day vulnerability, said Badhwar.

    Overall, the Dependency Lifecycle Management Platform improves the productivity of both application development and cybersecurity teams by streamlining vulnerability management, he added.

    Having a full understanding of their dependency graph also lets customers generate and analyze accurate software bills of materials (SBOMs) as applications are dynamically updated, noted Badhwar.

    In the wake of a series of high-profile breaches, there has been increased focus on software supply chains. The challenge is most developers don’t have a lot of cybersecurity expertise and, even when provided with tools to identify vulnerabilities, there are simply too many alerts generated. In the absence of any context, most of those alerts simply wind up being ignored. In the meantime, the rate at which new applications are being deployed and updated isn’t slowing down, especially as more organizations embrace cloud-native applications that make it easier to rip and replace software components.

    It’s going to take years for organizations to implement DevSecOps best practices to teach developers how to build more secure applications, but that journey needs to begin with tools that make it simpler for developers to address issues before applications are deployed. The best way to combat application vulnerabilities is to make sure they don’t manifest themselves in code in the first place. Based on the number of vulnerabilities that continue to find their way into application environments, it’s apparent that the current processes being used to build applications are fundamentally broken.

    At this juncture, it will take years to fix the application development and deployment process, but as more secure applications eventually replace millions of insecure applications the overall security posture of organizations will steadily improve. The issue now is finding ways to achieve that goal before another known vulnerability leads to another major security crisis.

  • Wipro Fires 2-Job Staff | Python Bug from 2007 | Lite Layoffs

    Wipro Fires 2-Job Staff | Python Bug from 2007 | Lite Layoffs

    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: Wipro fires 300 for moonlighting at competitors, Python has a nasty 15-year-old bug, and companies are finding new ways to lay people off without calling it a “layoff.” (more…)

  • DevOps World 2022: Developer and Security Links Protect Your Supply Chain

    DevOps World 2022: Developer and Security Links Protect Your Supply Chain

    Ever since the SolarWinds attack back in December 2020, software supply chain attacks have been top-of-mind for any company that builds software. The idea of endangering not just your organization by being attacked but also your customers really sharpens your focus.

    Another complicating factor is that applications use a combination of open software components and homegrown code to deliver applications. This software supply chain means your software can be compromised through no fault of your own but instead based on the components you use. The Log4j attack is an example of a component creating vulnerabilities in any software that uses it. So how do we defend our software? We need to think differently about where security starts and how security concepts can be integrated into software earlier in the development process where it interfaces with the rest of the technology infrastructure.

    Building a Secure Pipeline

    Modern software development is built on the CI/CD pipeline. It allows the application security testing and software composition analysis to happen way earlier in the integration process (shift left), and that allows you to identify and fix issues before the code gets anywhere near customers. Sounds simple, no? Just run your code through a pipeline, integrate security testing, identify issues, fix them, and deploy secure software.

    As with most things, what sounds simple in theory can be challenging to implement in reality. First, shifting left requires a collaboration between developers and security teams. Finding the security issues don’t matter if they don’t get fixed. To increase the likelihood of these issues getting fixed, the security team needs to provide context to the developers regarding the urgency of the flaw or vulnerability and some guidance on the best way to fix the issue. To be successful, security folks can’t just drop a report with hundreds of defects and vulnerabilities on the developers and expect that anything productive is going to happen. If this scenario reminds you of getting a report from your vulnerability scanner with hundreds of issues you won’t fix, well, that’s because it’s very similar.

    Second, security must add value to the development and architecture process by offering up infrastructure-as-code (IaC) templates and a toolchain that makes it easy to implement secure application stacks. Maybe that looks like a template library managed by a cloud security Center of Excellence, which can provide these tools across all of the application teams leveraging efforts.

    Combatting Supply Chain Attacks

    Finally, you can implement a security champions program, training a developer (or two) on each team about security issues and they can act as a security emissary to the developers. This provides scale, ensuring that the security team doesn’t become a bottleneck to fixing the security issues.

    Given the sophistication of the software, the attack surface of the code, and the velocity of the development process, combatting supply chain attacks requires tight and ongoing collaboration with the development team and shifting left to catch the security issues earlier in the integration process.

    Want to learn more about this and other related topics? Join CloudBees for DevOps World 2022, held in Orlando, Florida, at the World Marriott Center. Use discount code DW22 when registering and get access to all the fantastic offerings, including keynotes, sessions, training and other interactive activities. We can’t wait to see you there for the DevOps Remix!

  • DevOps World 2022: Using SBOMs to Secure the Software Supply Chain

    DevOps World 2022: Using SBOMs to Secure the Software Supply Chain

    As supply chain attacks become increasingly prevalent, visibility is emerging as a necessity in cybersecurity. One way to improve visibility and secure your software supply chain is with a software bill of materials (SBOM). 

    An SBOM is a list of all the components within a codebase. By providing insight into open source and third-party components, SBOMs improve overall visibility and are integral to the identification of security or license threats. To properly secure the software supply chain, organizations must have an understanding of all the components in their applications; it is especially important to do so with containerized applications and those built using cloud-native, microservices-based architectures. That’s why SBOMs are becoming a cornerstone of a comprehensive application security strategy. 

    The Need for Visibility

    Gartner’s recent report Innovation Insight for SBOMs emphasizes the need for constant visibility into the software development life cycle and how SBOMs can help organizations and developers achieve that goal. While Gartner recognizes that open source software is a foundational component of modern software development, it also noted that it can be a major contributing factor in software vulnerabilities. 

    “While reusable components and open source software have simplified software development, this simplicity has exposed a critical visibility gap: Organizations are unable to accurately record and summarize the massive volume of software they produce, consume and operate,” the report said. “Without this visibility, software supply chains are vulnerable to the security and licensing compliance risks associated with software components.” 

    To mitigate the associated risks, Gartner’s report not only emphasizes the importance of SBOMs but the need to automate the SBOM creation and validation process. To achieve supply chain security at scale, organizations should automatically generate and verify SBOMs and use that data to constantly evaluate oncoming risks. 

    This ties directly into the continuous integration and continuous deployment (CI/CD) process, which uses SBOM data and assessments to ensure threats don’t slip under the radar and wreak havoc. You can more easily identify security vulnerabilities at any stage in the pipeline and remove them—because an SBOM gives you more granular visibility.

    The importance of SBOMs has even been noted by the U.S. federal government. As stated in president Biden’s Cybersecurity Executive Order 14028, any company that sells software to the federal government will be mandated to provide a complete SBOM. 

    The initiative has also spread to other branches of the government, with the Cybersecurity and Infrastructure Security Agency also emphasizing the significance of SBOMs. 

    “CISA will advance the SBOM work by facilitating community engagement, development, and progress, with a focus on scaling and operationalization, as well as tools, new technologies, and new use cases,” said CISA in a statement on its website.

    SBOM Requirements

    The U.S. Department of Commerce and the National Telecommunications and Information Administration (NTIA) have outlined the minimum elements required. For one, data fields with baseline information about each component are required. Also, automation support is needed, as SBOMs necessitate machine readability for support at scale. Finally, the need for practices and processes was outlined, calling for frequent SBOM generation, including transitive dependencies and widespread availability of this information to those who need it. 

    On many fronts, SBOMs have become non-negotiable throughout the software industry. In order to effectively detect and respond to threats, organizations must take preemptive steps to ensure visibility is maximized, and SBOMs accomplish just that.

    Want to learn more about this and other related topics? Join CloudBees for DevOps World 2022, held in Orlando, Florida, at the World Marriott Center. Use discount code DW22 when registering and get access to all the fantastic offerings, including keynotes, sessions, training and other interactive activities. We can’t wait to see you there for the DevOps Remix!

  • GitLab To Embed Observability in CI/CD Platform

    GitLab To Embed Observability in CI/CD Platform

    The latest version of the GitLab continuous integration/continuous delivery (CI/CD) platform added a range of monitoring and visualization capabilities as part of an effort to embed a full set of observability capabilities in the core platform within the coming year.

    As part of that effort, the latest version of GitLab, 15.1, has now added support for all the metrics defined by the DevOps Research and Assessment (DORA) team that is also part of Google.

    In total, the 15.1 version of the GitLab platform has more than 30 updates. These include additional security capabilities in the form of support for the security assertion markup language (SAML) Group Sync and the Supply chain Levels for Software Artifacts (SLSA) framework defined by Google.

    Finally, GitLab added links to all configuration files and templates included in the CI/CD platform to the pipeline editor to make it easier to manage large and complex pipelines.

    Cindy Blake, director of product marketing for GitLab, said the monitoring, observability and security capabilities added to the platform are part of an ongoing effort to eliminate the ‘digital duct tape’ that many DevOps teams currently rely on to extend a CI/CD platform. In fact, as many DevOps teams look to better secure their software supply chains, many are now taking advantage of the moment to replace do-it-yourself (DIY) approaches with an integrated CI/CD platform based on a common codebase, noted Blake.

    As part of that effort, Blake said GitLab is building its own dynamic application security testing (DAST) tools that are more tightly integrated with its CI/CD platform.

    In general, there is now an expectation that the tools required to secure software supply chains should be made available within a CI/CD platform, but organizations are still working through the processes that will need to be implemented to achieve that goal, added Blake.

    It’s not clear to what degree organizations are looking to replace legacy CI/CD platforms as they modernize application development and deployment. In many cases, however, the technical debt associated with maintaining custom integrations across their DevOps environment has become considerable. Many organizations are revisiting their DevOps workflows as part of an effort to increase overall developer productivity. The challenge, of course, is that migrating from one CI/CD platform to another requires considerable time and effort.

    In the meantime, the number of organizations embracing DevOps best practices continues to grow. GitLab is betting that as the total size of the CI/CD market continues to expand, most of those organizations will prefer an integrated platform rather than writing and maintaining custom integrations themselves.

    Regardless of approach, the ability to monitor and observe workflows is an essential element of any DevOps workflow. There is, of course, no shortage of observability platforms available. It’s not clear whether IT organizations will adopt one of those offerings versus taking advantage of observability and monitoring embedded within a CI/CD platform. One way or another, however, it’s getting easier to discover the root cause of any IT issue.

  • DevOps Connect: DevSecOps — Building a Modern Cybersecurity Practice

    DevOps Connect: DevSecOps — Building a Modern Cybersecurity Practice

    Malicious actors are constantly looking for new ways to gain access to sensitive data and corrupt systems. As software supply chain attacks are on the rise, security has become a top priority and a growing area in the regulatory and standards landscape. DevOps teams need to approach security as an ongoing part of the software development cycle by implementing DevSecOps practices at scale to improve the security of their software supply chain and ensure the components of the application code are trustworthy.

    At DevOps Connect: DevSecOps Virtual Summit, on July 12, we’ll share exclusive content from our RSAC 2022 event to help DevOps teams integrate security in their process from the start. Internationally recognized DevOps and security leaders will examine the supply chain risk landscape, market trends and practical solutions, and provide strategic insights on emerging regulatory topics.

    Attendees will gain valuable insider knowledge, tips and tricks they can share with their team and immediately put into practice to build a modern cybersecurity practice within their company.

    Things You’ll Learn

    The agenda features a mix of DevOps and cybersecurity topics, including:

    • AppSec and DevSecOps best practices
    • SBOMs and security regulations
    • API, open source and supply chain security
    • Cloud and Kubernetes security risks
    • Pentesting at scale
    • The three ways of DevOps
    • Shift-left security
    • Open Zero Trust
    • And more

    Meet the Speakers

    The speaker lineup features some of the foremost innovators in the DevSecOps community, including:

    • Jim Zemlin, executive director at the Linux Foundation
    • Chenxi Wang, founder and general partner at Rain Capital
    • Jennifer Czaplewski, senior director of cybersecurity at Target
    • John Willis, senior director of the global transformation office at Red Hat
    • Caroline Wong, chief strategy officer at Cobalt
    • Priyanka Sharma, executive director at CNCF
    • Dr. Amit Elazari, director of global cybersecurity policy at Intel Corp
    • Cherilyn Pascoe, senior technology policy advisor at National Institute of Standards and Technology (NIST)
    • Larry Maccherone, DevSecOps transformation architect at Contrast Security
    • Tracy Bannon, senior principal at The MITRE Corp
    • And many others

    Visit the Exhibit Hall

    In addition to the sessions, attendees can visit the virtual exhibit hall to interact with partner sponsors including Sysdig, Sonatype, Check Point Software Technologies, Prisma Cloud, SUSE, Qualys, Traceable AI and more. The expo hall will be open throughout the event, giving attendees the opportunity to chat with the sponsors and download information at any time.

    Registered attendees will also receive a link to access the virtual environment on-demand. To see the full agenda and to register for free, please visit the DevOps Connect: DevSecOps Virtual Summit website.

  • Codenotary Adds SLSA Framework Support to Advance App Security

    Codenotary Adds SLSA Framework Support to Advance App Security

    Codenotary this week announced it has integrated support for the Supply-Chain Levels for Software Artifacts (SLSA) framework in its free notarization and verification service for ensuring the integrity of code.

    Moshe Bar, Code Notary CEO, said as the first application security platform to attain SLSA compliance, the company is making it easier for organizations to secure their software supply chains.

    SLSA is a framework defined by Google that it uses to attach binary authorization to code. In its current form, SLSA is a set of guidelines that identify how to attain four different levels of application security. The long-term goal is to create a framework that will automatically generate auditable metadata that can be fed into policy engines to create a SLSA certification.

    Codenotary provides tools for cataloging and verifying the authenticity of components used with a software development life cycle. At the core of that platform is an immutable open source immudb database that cryptographically attaches an identity to each software artifact. That capability can also be used to dynamically generate a software bill of materials (SBOM).

    The Codenotary Attestation Service can also be integrated with the continuous integration/continuous delivery (CI/CD) platform that DevOps teams use to build and deploy applications using those artifacts. Ideally, DevOps teams should construct a security pipeline that runs alongside their existing DevOps pipelines, noted Bar.

    In the wake of recent high-profile software supply chain breaches, the level of scrutiny being applied to how software is constructed has increased significantly. In theory, at least, developers have assumed more responsibility for application security as part of an overall shift left that provided them with more programmatic control over IT environments. Cybercriminals, however, are now becoming more adept at compromising developers’ credentials and insert malware as an app is developed.

    DevSecOps best practices are, of course, being adopted to teach developers how to better secure their application environments. The issue is that not enough developers are learning how to secure applications fast enough. The volume of attacks against the software supply chain continues to grow at a rate that is now much faster than organizations can thwart simply by educating developers.

    There is a now clear need to embed more cybersecurity guardrails within DevOps workflows, noted Bar. Rather than attempting to achieve that goal in a piecemeal fashion, Bar said Codenotary is making a case for an integrated platform that can be invoked as a natural extension of a DevOps workflow.

    In general, Bar said there’s now a greater sense of urgency when it comes to software supply chain security. Many of the reviews of those processes are, arguably, long overdue. One way or another, there will be a lot more questions asked about how software is actually developed. The organizations that consume this software are starting to appreciate how vulnerable they are as the overall dependency on software continues to increase. The only real question now, unfortunately, is how many more breaches there might be before those software security issues are thoroughly addressed.

  • Survey Surfaces Raft of Application Security Issues

    Survey Surfaces Raft of Application Security Issues

    A global survey from ReversingLabs found 87% of respondents agreed that software tampering has become a more frequently-used cybersecurity attack, but only 37% said they have any means to detect it.

    The survey, which polled 300 IT and security professionals, was conducted by Dimensional Research on behalf of ReversingLabs, a provider of a platform for analyzing any file, binary or object. Despite software tampering’s frequency, only 7% of survey respondents said they could detect software tampering at each phase of the software development life cycle.

    Just as troubling, only slightly more than half (51%) reported being able to protect their software supply chain with only a third being able to actually check for tampering once an application is final and deployed, the survey found.

    Overall, more than half of respondents (54%) said their organization knowingly released software with potential security risks. Nearly every respondent (98%) also acknowledged that reliance on third-party software use, including open source software, increases security risks.

    On the plus side, more than three-quarters of respondents (77%) said they appreciated the value of a software bill of materials (SBOM) that makes it possible to ascertain what software artifacts are being employed within an application. However, only 27% of respondents said their organization currently generates and reviews SBOMs. A full 90% said they are finding it increasingly difficult to create and review SBOMs. Nearly half of the survey respondents reported that SBOM processes today involved manual steps.

    Other SBOM hurdles respondents cited included lack of expertise (44%) and inadequate staffing to review and analyze SBOMs (44%).

    ReversingLabs CEO Mario Vuksan said that while it’s still early days as far as SBOM capabilities are concerned, a series of high-profile zero-day vulnerabilities has forced the issue into the spotlight. Organizations are now spending months looking for every possible instance of newly discovered vulnerabilities because no one is quite sure what application components are running across an extended enterprise, he noted.

    However, as DevSecOps best practices continue to evolve and mature, it’s also clear that SBOMs will play a critical role in securing software supply chains, Vuksan added. The challenge is that in the age of microservices, application environments are now much more dynamic as components are ripped and replaced with greater frequency, he added.

    SBOMs, of course, are just one element of what will be required to secure a software supply chain. Many organizations are now reviewing their software development processes and uncovering uncomfortable truths about how software is currently built and deployed. The ultimate goal is not to slow down the rate at which software is developed but to make sure there are guardrails in place that prevent insecure software from being deployed in the first place. Far too many developers today still view cybersecurity reviews as tasks to be avoided in the name of meeting an application deployment deadline.

    Hopefully, that won’t continue to be the case as more responsibility and accountability for applications security shifts left toward developers and DevOps teams. In the meantime, however, when it comes to application security, it’s apparent there’s still much room for improvement.

  • Survey Sees Little Progress on Securing Software Supply Chains

    Survey Sees Little Progress on Securing Software Supply Chains

    A survey of 1,750 IT security decision-makers published today found that, despite a series of high-profile cybersecurity breaches, nearly two-thirds (62%) of respondents have done nothing to secure their software supply chain. A full 64% conceded that an attack against their software development environment could not be stopped. And nearly three-fourths (71%) of respondents admitted their organization suffered a successful software supply chain-related attack that resulted in data loss or compromise of an asset, while 85% acknowledged a software bill of materials would also reduce the risk of compromise to a software supply chain.

    The survey, conducted by the market research firm Vanson Bourne on behalf of CyberArk, a provider of a privileged access management (PAM) platform, also found that 87% of respondents stored secrets in multiple places across DevOps environments, while 80% conceded developers typically have more privileges than necessary for their roles. Only 3% of respondents said their organization has a centralized secrets management platform to manage credentials used by applications.

    Organizations are also struggling to keep pace with the number of digital identities that have access to IT services. The average staff member has access to more than 30 applications and accounts, the survey found. However, 68% also reported non-humans or bots have access to sensitive data and assets, with machine identities now outnumbering human identities by a factor of 45, on average, the survey found. Less than half (48%) of respondents have any type of identity security controls in place for their business-critical applications.

    Even the threat of ransomware doesn’t seem to be having much of an impact. More than 70% of respondents said their organization has experienced, on average, two ransomware attacks in the past year.

    Brandon Traffanstedt, senior director for the global technology office at CyberArk, said it’s apparent organizations are accruing a significant amount of security debt that is not being proactively addressed. In fact, more than two-thirds of respondents (69%) said their organization has prioritized maintaining business operations over ensuring robust cybersecurity in the last 12 months. A full 99% of respondents said their organization had fast-tracked the adoption of at least one business/IT initiative over the last 12 months.

    In general, hybrid working (86%), the introduction of new digital services for customers or citizens (84%) and increased outsourcing (84%) are identified as the activities that are introducing the greatest risks. Specifically, the survey found credential access (40%) was the number one area of risk, followed by defense evasion (31%), execution (31%), initial access (29%) and privilege escalation (27%).

    Real-time monitoring and analysis to audit all privileged session activity; least privilege security/zero-trust principles on infrastructure that run business-critical applications and processes to isolate business-critical applications from internet-connected devices to restrict lateral movement are tied at 54% for the top three security initiatives organizations are planning to implement. The top three strategic zero-trust initiatives are workload security (52%), identity security (50%) and data security (45%), the survey found.

    Ultimately, the only way to address the current level of security debt organizations are incurring is by embedding functionality into DevOps workflows that automatically apply security policies and teaching developers to build more secure applications, said Traffanstedt. The former approach, however, may have a bigger impact more quickly, given the current level of cybersecurity expertise that currently exists in the developer community.

  • How to Mitigate Software Supply Chain Risks

    How to Mitigate Software Supply Chain Risks

    As new vulnerabilities are discovered on a daily basis, DevOps teams must integrate security into the early stages of the development lifecycle and be vigilant about what elements are incorporated into their applications.

    The Log4J vulnerability has dominated the headlines since it was discovered in December and it continues to send shock waves through the industry. Any application that uses Log4J is subject to the identified family of attacks known as Log4Shell.

    Many tech companies have been impacted by the Log4J vulnerability and it has become a major concern for DevOps teams.

    On March 1, cybersecurity experts from Snyk will come together at Know Your Code: Open Source and Supply Chain Summit to discuss future strategies for maintaining security throughout your software supply chain and the security of open source packages.

    The experts will lead a live panel based on the learnings from the Log4Shell vulnerability and several real-world remediation approaches as well as other fixes outside of code. The panel features demos on container and IaC hacks and Java-based game hacks.

    The sessions explore the software supply chain as an attack vector, how developers are targeted as a vehicle for malware distribution, how immensely we depend on open-source maintainers to release timely security fixes and how the race to the cloud creates new security concerns for developers to cope with, as computing resources turn into infrastructure as code.

    Meet the Speakers

    • Mic McCully, field director at Snyk
    • Simon Maple, field CTO at Snyk
    • Micah Silverman, director of developer acceleration at Snyk

    Agenda

    • Welcome (11 a.m. to 11:05 a.m. ET)
    • Are We Forever Doomed By Software Supply Chain Risks? (11:05 a.m. to 12 p.m. ET)
    • Coffee Break (12 p.m. to 12:05 p.m. ET)
    • Log4Shell Live Hack: A Hands-on, Actionable Fix Guide (12:05 p.m. to 1 p.m. ET)
    • Break (1 p.m. to 1:05 p.m. ET)
    • Mitigating Risks in Software Supply Chain Security (1:05 p.m. to 2 p.m. ET)

    For more information and to register, please visit the Know Your Code: Open Source and Supply Chain Summit website.