staging-devopsy.kinsta.cloud

Tag: devsecops

  • Codenotary Previews Secure SBOM Creation Service

    Codenotary Previews Secure SBOM Creation Service

    Codenotary today made available a preview of a centralized repository service for generating and storing software bills of materials (SBOMs) that makes it simpler to securely share them as necessary.

    Moshe Bar, Codenotary CEO, said SBOMCenter will make it easier for organizations to operationalize SBOMs that are being created with greater frequency as the need for increased focus on securing software supply chains grows.

    Currently available as a free trial, Codenotary’s SBOMCenter provides a way to create and store SBOMs in a way that ensures they have not been tampered with, noted Bar.

    Implementing SBOMs can be a cumbersome process that can require changes to existing software development and procurement practices. The SBOMCenter provides a service for accessing SBOMs that are continuously updated using an immutable open source database that supports multiple SBOM formats and a tool the company developed that automatically generates SBOMs by adding a single line of code. That approach should make it simpler to identify what software components are running in a production environment any time a new zero-day vulnerability is discovered.

    In a future update to SBOMCenter, the company said it plans to add vulnerability scanning, risk exposure scoring, alerts on newly discovered vulnerabilities and a policy enforcement engine that can be integrated with DevOps pipelines.

    Awareness of the need for SBOMs has increased dramatically since the Biden administration’s executive order made it clear that federal agencies would require them from any software provider starting next year. Many enterprise IT organizations are likely to follow suit as part of a larger effort to better secure software supply chains in the wake of a series of high-profile cybersecurity breaches.

    More recently, a National Cybersecurity Strategy paper published by the White House calls for increased liability for software developers that fail to exercise due cybersecurity diligence when building applications. It’s not clear if there will ever be a law on the books that would enable penalties to be applied, but the general mood is clearly shifting toward holding organizations that build software more accountable for cybersecurity issues that might arise.

    It’s not yet clear how far down the path organizations are toward operationalizing SBOMs. Gartner predicted that, by 2025, a full 60% of organizations will be employing SBOMs. In theory, those organizations should be able to prevent software with unverified components from being deployed in production environments and identify which applications currently running have significant flaws.

    On way or another, application providers will find themselves disclosing more about how their software is constructed. The issue now is finding a way to accomplish that goal in a way that respects intellectual property rights. As such, application providers need to find a secure way to share SBOMs with customers that will commit to making sure the contents of those SBOMs stay private. After all, a little cooperation from the coalition of the willing is likely to have a more positive impact than a law that is likely to be challenged.

  • Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode has added a module to its platform for mapping metadata and events using graph technology that makes it simpler for application development and cybersecurity to consolidate alerts generated by their DevSevOps tools.

    Lotem Guy, vice president of product for Cycode, said the Cycode Application Security Orchestration and Correlation (ASOC) module will automatically discover all the tools that make up a DevSecOps workflow without requiring any integration effort.

    That capability makes it simpler to aggregate results in a way that enables development teams and cybersecurity professionals to identify the most critical issues that need to be addressed before applications are deployed in production environments, he added.

    In effect, Cycode is now providing a method for bridging the historic divide between cybersecurity professionals and application development teams. More cybersecurity professionals are embedded within DevOps teams, but in the absence of a platform for aggregating alerts, they often encounter communications issues. ASOC provides an agentless approach to aggregating the data that DevSecOps teams need to prioritize remediation efforts, said Guy.

    While a lot of progress has been made in terms of adopting DevSecOps best practices, many organizations still struggle with securing their software supply chains. Most of the members of a DevOps team have limited cybersecurity expertise, so they need the help of a cybersecurity professional to determine what specific actions are required to remediate a vulnerability. Cybersecurity professionals, conversely, don’t have a lot of application development expertise and generally would prefer not to be overwhelmed by multiple DevOps tools generating alerts about the same potential application security issue.

    As the number of regulations specifically focused on application security steadily increase, it’s now just a question of time before every organization that builds software will need to embrace DevSecOps. The challenge is that while everyone involved generally agrees software should be more secure before it’s deployed, the security tools made available to DevOps teams vary widely. In fact, it’s not uncommon for DevOps teams to find themselves spending significant amounts of time sorting through multiple conflicting alerts.

    Nor is every alert that gets generated relevant—in some cases, a specific module that generated an alert might not find its way into the final application. In addition, many of the alerts generated also tend to lack context about severity. Application developers can’t devote all their time to fixing bugs, so choices will need to be made based on the actual risk to the application.

    Cycode is betting that, as DevSecOps continues to evolve, organizations will look for tools and platforms that make it simpler to make sense of the current level of application security chaos that tends to pervade IT organizations. In the meantime, cybersecurity professionals and application developers will need to learn to trust one another. Developers have too often viewed cybersecurity as an obstacle to deployment while cybersecurity teams have historically considered developers to be one of the primary causes of the breaches they are expected to clean up. The first step toward achieving that goal is, of course, to realize that neither is really the enemy of the other.

  • GitLab Survey Reveals DevSecOps Gains

    GitLab Survey Reveals DevSecOps Gains

    A global survey of 5,010 IT leaders, CISOs and developers published by GitLab this week found well over half (56%) of respondents are working for organizations that are using DevOps or DevSecOps practices. However, 72% of respondents said they are using a DevSecOps platform (36%) or are considering adopting one in the next year (36%).

    Overall, less than a third of survey respondents (30%) said they were “completely” responsible for application security, with 53% reporting they are part of a larger application security team. Well over a third (38%) of the 1,453 security professionals surveyed said they are part of a cross-functional team focused on security.

    License compliance checks and security capabilities for cloud-native or serverless tied for the top of the list of current priorities (19%), but shifting security left (29%) was the top focus for the coming year. Nearly three-quarters (74%) of security professionals said their organizations either shifted left or plan to in the next three years. Nearly as many (71%) said a quarter or more of all security vulnerabilities were discovered by developers.

    Top frustrations identified specifically by security professionals included testing happening too late in the development cycle (43%) and difficulty prioritizing vulnerability remediation (41%).

    Those frustrations might increase in the coming year, with 85% of security professionals reporting they either have the same or lower budget in 2023.

    On the plus side, nearly two-thirds of the 1,954 developers surveyed said they are either using artificial intelligence (AI) and machine learning (ML) algorithms in testing today or will be in the next three years. A full 62% said they used AI/ML to check code, while 53% use bots for testing and 36% use AI/ML for code review.

    Nevertheless, more than two-thirds of security professionals (67%) said they are concerned about the impact of AI/ML capabilities on their job, with 28% of them admitting they are “very” or “extremely” concerned. Of those respondents who expressed concern, 25% said they are worried about the potential for AI/ML to introduce errors that will make their job more difficult.

    David DeSanto, chief product officer at GitLab, said GitLab is also working to address those concerns by embedding a range of AI/ML capabilities into its platform to optimize DevSecOps workflows and, most recently, enhanced its GitLab Remote Development module to make it easier to centralize the maintenance and security of development environments.

    GitLab this week also announced it is partnering with Oracle to make it easier to use the GitLab continuous integration/continuous delivery (CI/CD) platform to run AI and ML workloads on the Oracle cloud platforms. AI/ML is going to play a critical role in enabling organizations to build and deploy secure code without slowing down the pace of application development, said DeSanto. In fact, many organizations will soon be consolidating toolchains to enable them to achieve that goal, he added.

    The GitLab survey found 57% of security respondents said they use six or more tools, but many of those tools are legacy software composition analysis (SCA) tools that will be replaced as more responsibility for application security shifts left toward developers, noted DeSanto. Two-thirds of survey respondents (66%) reported they want to consolidate their toolchains this year.

    Collectively, the GitLab survey makes it clear that DevOps and DevSecOps practices and platforms continue to evolve rapidly. The challenge, as always, is keeping up with the pace of that change.

  • How Application Developer Turnover is Shaping Security

    How Application Developer Turnover is Shaping Security

    Observing the developer job market for the past two years reveals a surprising truth that has a profound impact on technology organizations. In the “new normal” of hybrid work, life moves fast and there’s no sign of slowing down. Since 2021, we’ve witnessed all-time record demand for software engineering developers. The emergence of privately held large and medium technology startups, fueled by a fear of missing out (FOMO) driven venture capital market, created vast growth opportunities for software engineer developers in particular. From developing and deploying new applications to scaling your business through multi-cloud environments, cloud and cloud-native companies are everywhere. Not only are cloud and cloud-native companies receiving enormous funding rounds, but worldwide spending on public cloud services is forecasted to grow 20.7% to a total of $591.8 billion in 2023.

    This dramatic cloud growth is primarily driven by the warp speed developers are operating. Thanks to developers, every company is now a digital company and every industry is reaping the benefits of a cloud presence. A retail organization can now build and deploy an application for the holiday shopping season within hours, and workforces can access applications from their kitchen, local coffee shop, or halfway across the world.

    However, as with any new, widely adopted technology, cybercriminals look to target and exploit organizations in their early cloud days as they begin to grasp and understand the technology.

    It was reported earlier this year that the recent exposure of roughly a terabyte of Pentagon emails was likely due to a cloud configuration error. Cloud attacks are on the rise, and there is a major disconnect about who is responsible for keeping the organization safe. Developers who are told to build with speed don’t want their applications slowed down or user experience to be altered by security protocols. Still, accelerating application velocity has security teams caught between remaining responsive to application teams and securing an increasingly complex cloud environment. A major problem is bubbling up, and if security and developers teams cannot come together, the result can leave organizations vulnerable.

    Developers and Turnover

    In a recent survey, 75% of respondents reported a higher-than-usual turnover rate in DevOps. Similar to the well-documented cybersecurity talent shortage, multiple workplace stressors appear to be taking a toll on developers. The same survey reported that 38% of enterprises deploy code to production or release to end users every day, with 17% deploying multiple times a day. To put this into perspective, just two decades ago, developers were shipping limited updates one to two times a year.

    Given the pressure to deliver new code every day, combined with security teams’ pressure to ensure that code is secure, it’s no surprise that we’re witnessing higher-than-normal developer attrition. Instead of pointing fingers at developers for unsecure code, security teams need to create tools and training that do not impede their number one priority: Shipping new code. We’re in a developer-friendly job market and organizations cannot afford to lose top talent because they are overburdening them with security tasks. Developers will find greener pastures.

    Shifting Left

    By now, everyone in the industry has heard of shifting security left—the practice of moving security to the earliest possible point in the development process to ensure code is secure and limit timely and costly remediation. In practice, this means bringing security to where the developers operate so vulnerabilities and misconfigurations are caught early when they are easy to fix.

    This approach has brought about a deeper level of engagement between application developers and security teams, especially in the design phase. However, while developers might now be embracing tools and processes that help them code secure applications, there’s still a limit to how much shift left responsibility they can and want to handle.

    Path Forward

    Shifting security left is certainly a recommended starting point, but simply equipping developers with DevSecOps tools isn’t a winning approach. Developers must be trained and have the desire to effectively use the tools. Like the old saying, give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime. The same holds when shifting security left.

    To ensure developers and security teams understand their security responsibilities within the organization, consider implementing the following:

    1. Define a clear shift left strategy with developers and security teams
    2. Provision the necessary security tools that effectively protect the organization but don’t create roadblocks for developers. Additionally, more tools don’t necessarily mean more security, so be strategic.
    3. Train developers to be more mindful of cybersecurity issues. Most developers haven’t had formal cybersecurity training, so it’s up to organizations to make sure that particular skills gap is closed

    DevSecOps is as much about changing culture and approaches as it is about acquiring new tools. Developers will, unfortunately, come and go, but it should never be because security teams are overburdening them.

  • A DevOps Guide to the Language of DevSecOps

    Security is increasingly important for DevOps due to the growing complexity of applications and the accelerated pace of development. As organizations adopt DevOps practices, they face new challenges in securing applications and infrastructure:

    • Increased complexity and automated processes: With automation at the core of DevOps, processes and applications are more intricate. This can introduce vulnerabilities if not carefully managed and secured, as they often involve multiple systems and components that need to be protected.
    • Reliance on code repositories: DevOps teams depend heavily on code repositories for version control and collaboration. However, these repositories can be targets for attackers seeking to inject malicious code or steal sensitive information, making it crucial to secure access and maintain good security practices.
    • Larger attack surface: The DevOps pipeline consists of numerous tools and components, including source code management, build systems, testing frameworks and deployment tools. Each of these elements presents potential attack surfaces and needs to be secured to protect the overall application.
    • High-velocity development: The rapid pace of development in a DevOps environment can sometimes lead to security being overlooked or deprioritized. As new features are pushed out quickly, there may be less time for thorough security reviews.
    • Tooling limitations: While many DevOps tools come with built-in security features, these may not be sufficient to protect against all threats. Relying solely on these features could create a false sense of security, leaving organizations exposed to potential attacks.

    What is DevSecOps?

    DevSecOps enables teams to shift security left and integrate it continuously across the entire SDLC rather than as an afterthought. It is a cultural shift even for DevOps teams, as it requires all members to adopt a security mindset that ensures software is not only released fast and at the highest possible quality but also includes all security measures and checks from the design phase.

    It typically involves adopting secure coding practices and implementing application security testing tools that help design, test, verify, release, and update secure software in a secure manner. It requires ensuring that not only the software itself is secure, but also the development environment and the entire supply chain is secure. As a result, DevSecOps rely on a high level of automation tools to reduce manual work to a minimum.

    DevOps Guide to Security Acronyms

    All DevOps pros need to become familiar with key security concepts. Here are a few concepts that will help you communicate better with security teams in your organization and one day become a DevSecOps geek yourself.

    1. SBOM—Software Bill of Materials

    A software bill of materials (SBOM) comprises all components and software dependencies in the application’s build and delivery. It provides visibility into all the different components and licensing included in a piece of software to help discover potential vulnerabilities and licensing risks.

    2. DAST – Dynamic Application Security Testing

    DAST involves analyzing applications or services while they are running to identify security vulnerabilities. This technique typically simulates attacks to learn how a malicious actor might exploit the user or application interface. Teams use DAST tools to detect complex vulnerabilities caused by specific functionality that a static analysis tool cannot find when analyzing the source code.

    3. SCA – Software Composition Analysis

    SCA tools identify security vulnerabilities in third-party components and dependencies. Teams can integrate SCA to run across the entire development pipeline to build an open source dependency tree for the application and map these components against a database of known vulnerabilities. The tool generates reports on vulnerable open source components found in the application that require fixes or patches.

    4. SAST – Static Application Security Testing

    SAST tools analyze the source code of applications, services, and microservices, trying to identify potential vulnerabilities caused due to insecure coding practices. Teams can integrate SAST tools into their continuous pipeline, setting them up to automatically search the source code for coding patterns and insecure objects or functions that can result in security vulnerabilities. SAST is commonly used to identify vulnerabilities during the coding phase or when pushing code to a testing environment.

    5. IAST—Interactive Application Security Testing

    IAST involves analyzing the source code for vulnerabilities while the application is running. The main advantage of IAST is that this method reports vulnerabilities in real-time and does not add additional time to the CI/CD pipeline. It works from within the application, distinguishing it from both SAST and DAST techniques that work externally. IAST does not scan the entire codebase. Instead, it checks only the aspect exercised during the functional test.

    6. RASP—Runtime Application Self-Protection

    RASP is a defensive technique built into the tested application to detect and respond to attacks as they occur. It is typically implemented using third-party tools embedded within the application to monitor incoming requests and the application’s behavior, such as packages, plug-ins or libraries. These components inspect requests and the application’s behavior to block and protect against threats.

    7. OWASP—Open Web Application Security Project

    OWASP is a nonprofit devoted to helping improve software security by offering free resources and tools. This organization consists of a large community of volunteers who help propose, build and manage projects and educational materials that support the wider software development and security community.

    8. XDR—Extended Detection and Response

    XDR solutions collect and correlate deep activity data and detections across various security layers, including endpoints, emails, servers, networks, and cloud workloads, performing automated analysis to help detect threats faster. Teams can use this information to take quicker action during investigations. The main advantage of XDR solutions is that they help break down the security silos that allow stealthy threats to evade detection. 

    9. XSS—Cross-Site Scripting

    XSS is a security vulnerability. It plagues so many web applications that it has yet to be removed from the OWASP Top 10 web vulnerabilities list since it was first included in the 2003 version. XSS vulnerabilities enable threat actors to execute malicious script code in one or multiple users’ browsers. Actors often use XSS to gather sensitive information, such as user session details and personal data. 

    10. SQLi—SQL Injection

    SQLi is a code injection technique that enables threat actors to attack applications. It typically occurs when applications require user input, such as usernames, but receive a malicious SQL statement instead. To launch this attack, actors must locate vulnerable user inputs in the web application, create input content and send it. If the database executes the malicious SQL command, the attacker gains access to the database.

    11. CSRF—Cross-Site Request Forgery

    CSRF is a common web application attack that exploits the trust between a user and an application to conduct various malicious actions. Threat actors use CSRF to hijack an authenticated session between a user’s browser and an application. Once actors have access to the session, they can use it to execute functionality on that application.

    12. SAML—Security Assertion Markup Language

    SAML is a standard used to securely share information about identities, authentication, and authorization between various systems. It is typically implemented with the Extensible Markup Language (XML) standard for data sharing and often provides an open framework to implement a federated identity system like single sign-on (SSO). 

    Conclusion

    In today’s chaotic cyber landscape, DevOps teams cannot solely prioritize the fast release of high-quality software. To ensure their software, infrastructure and development environment are protected, DevOps teams must integrate security into the entire SDLC. This endeavor requires adopting a security mindset and utilizing tools that help create an efficient and secure pipeline. 

    The acronyms discussed in this article include essential security aspects DevOps teams should get familiar with, such as the OWASP organization that provides important guidance on building secure software, tools that help shift security left and common web vulnerabilities. However, teams should branch beyond these practices and tools to create a comprehensive security policy that covers their unique needs and requirement.

    Image Source 

  • Android Apps Must Let Users Delete Data ¦ RISC-V in the Data Center

    Android Apps Must Let Users Delete Data ¦ RISC-V in the Data Center

    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: Google forces apps to make deleting users’ data easier, and the RISC-V drumbeat grows louder. (more…)

  • Synopsys Preps Extensions to Polaris SaaS Platform

    Synopsys Preps Extensions to Polaris SaaS Platform

    Synopsys plans to extend the capabilities of its Polaris Software Integrity Platform for securing application development environments by adding dynamic application security testing (DAST) tools along with the ability to scan code used to provision infrastructure.

    As a software-as-a-service (SaaS) platform, the Polaris Software Integrity Platform was created by combining the static application security testing (SAST) tool Synopsys gained with the acquisition of Coverity in 2014 and the software composition analysis (SCA) tool it added to its portfolio by acquiring Black Duck Software in 2017.

    In 2015, Synopsys acquired the Seeker tool for analyzing the code created using interactive application security testing (IAST) tools from Quotium. The company last year acquired WhiteHat Security from NTT to add a DAST tool.

    Patrick Carey, senior director for marketing strategy for Synopsys, said that the company would add the capabilities of those latter two platforms to create a comprehensive set of best-in-class security tools that are easily accessible via a SaaS platform.

    At a time when more organizations than ever are moving to secure software supply chains, Carey said it’s critical to provide developers with more visibility into vulnerabilities across the entire software development life cycle (SDLC). Some organizations are opting to achieve that goal by embedding tools within the SDLC themselves, but many organizations would likely prefer to invoke a SaaS platform that they don’t have to maintain, noted Carey.

    He noted that a SaaS platform makes it simpler to point a collection of integrated tools at a code repository to surface those vulnerabilities.

    As DevSecOps workflows continue to evolve and mature, more responsibility for application security is shifted left toward developers. The challenge is that many developers have limited cybersecurity expertise, so it’s critical that they have access to high-quality security tools.

    In addition, a SaaS platform helps reduce the total cost of achieving that goal by providing multiple capabilities within a single integrated platform, said Carey.

    Naturally, most of the focus today is on reducing the number of vulnerabilities that find their way into production environments as applications are being built. However, there are already large numbers of unaddressed vulnerabilities in applications that have already been deployed. Organizations will need to find ways to address that technical debt in addition to providing developers with tools that help prevent those code vulnerabilities in the first place.

    As such, there is no one central place through which application security can be managed, noted Carey. Instead, application security needs to be addressed across every phase of the SDLC, he added.

    It’s not clear how quickly organizations are adopting DevSecOps best practices, but as calls for increased liability for software development increase—as outlined, for example, in the U.S. National Cybersecurity Strategy— organizations should expect DevSecOps workflows to become a requirement. Otherwise, organizations will be severely penalized for vulnerabilities that find their way into code. In effect, there is now a race to embrace DevSecOps before any proposed liability legislation becomes the law of the land.

  • Software Supply Chain Risk Management: A 2023 Guide

    Software Supply Chain Risk Management: A 2023 Guide

    Software supply chain risk management (SSCRM) refers to the process of identifying, assessing and mitigating risks associated with third-party software components and services that are integrated into software products. SSCRM involves understanding the potential vulnerabilities that may arise from these components and taking measures to reduce the risk of exploitation or compromise to the software system or end-users.

    Why Software Supply Chain Attacks are Becoming More Common

    Software supply chain attacks have become common due to several factors: 

    • Larger attack surface: The increased use of third-party software components and services in software development has expanded the attack surface for cybercriminals. This means that attackers can exploit vulnerabilities in these third-party components to gain access to the larger software system. 
    • Rise of open source: The proliferation of open source software has also contributed to the rise of supply chain attacks as attackers can inject malicious code into open source repositories, which can then be used by developers in their software products.
    • Difficulty to detect: Detecting supply chain attacks can be challenging since attackers often use legitimate-looking code that may be difficult to distinguish from normal code. This can make it difficult for traditional security measures to detect the attack. Additionally, the attack may not manifest itself until much later, making it even harder to trace back to its source.
    • Automation: Supply chain attacks are also becoming more sophisticated through the use of automation. Attackers can use automated tools to scan for vulnerabilities in third-party components and inject malicious code into them. This means that they can quickly and efficiently compromise a large number of software products.
    • Evasion techniques: Attackers can evade traditional security measures through techniques such as code obfuscation and encryption. This makes it difficult for security measures to detect malicious code, which can easily slip through undetected.
    • Sophistication: Supply chain attacks are becoming more challenging to combat due to the use of advanced malware techniques to change shape. Attackers can use polymorphic malware that can change its code and behavior to avoid detection. This means that even if the malware is detected, it can quickly change its form to evade detection in the future.

    Supply Chain Security and DevSecOps

    DevSecOps is an approach that integrates security into all stages of the software development process. Adopting DevSecOps practices can help businesses manage supply chain risks by building security into their software development and delivery pipelines. 

    Continuous integration/continuous deployment (CI/CD) pipelines are a key component of DevSecOps, as they allow developers to rapidly test and deploy code changes while ensuring that security and compliance requirements are met.

    Here are some ways DevOps tools in the CI/CD pipeline can help manage supply chain risks:

    • Automating security testing: DevSecOps enables businesses to automate security testing throughout the software development life cycle, including during the development, testing and deployment phases. This can help identify and mitigate security vulnerabilities early in the process, reducing the likelihood of supply chain risks.
    • Continuous monitoring: DevSecOps enables continuous monitoring of software and infrastructure, providing real-time visibility into the security posture of the supply chain. This can help identify and respond to security threats quickly and effectively.
    • Secure coding practices: DevSecOps encourages the use of secure coding practices, such as input validation, access control and error handling, reducing the likelihood of supply chain risks.
    • Risk management: DevSecOps incorporates risk management into the software development process, ensuring that supply chain risks are identified, assessed and managed effectively.

    Tools and Solutions to Help Manage Supply Chain Risks

    Supply Chain Risk Management (SCRM)

    SCRM solutions are software tools and services that help organizations manage and mitigate supply chain risks. These solutions provide visibility into the supply chain operations, identify potential risks and enable organizations to take proactive measures to mitigate these risks. 

    They may include features such as supplier risk assessments, real-time monitoring of supply chain operations, analytics and reporting and incident response planning. SCRM solutions are often available as a service (SaaS) and can help organizations to enhance supply chain resilience, reduce disruption and ensure business continuity.

    Software Composition Analysis (SCA)

    Software Composition Analysis (SCA) is a software security practice that involves identifying and managing open source and third-party components used in the development of software applications. SCA tools scan the software codebase, detect and report the presence of third-party and open-source components and identify known vulnerabilities in these components. 

    SCA helps organizations to identify and manage risks associated with third-party components, including license compliance, intellectual property infringement and security vulnerabilities. SCA is an essential component of SSCRM and can help organizations to ensure the security and integrity of the software products they develop and distribute.

    Third-Party and Supplier Risk Management

    Third-party and supplier risk management software is designed to help businesses manage the risks associated with their third-party vendors and suppliers. This software provides tools and resources to identify, assess and manage the risks associated with third-party relationships.

    Here are some features of third-party and supplier risk management software:

    • Supplier management: The software provides tools to manage supplier relationships, including supplier performance monitoring, supplier compliance and supplier risk assessment.
    • Risk assessment: The software enables businesses to assess the risks associated with their third-party relationships, including financial risks, operational risks and reputational risks.
    • Compliance management: The software helps businesses comply with regulations and standards, such as GDPR, HIPAA and ISO 9001.
    • Data analytics: The software uses data analytics tools to help businesses identify trends and patterns in third-party data, enabling them to anticipate and mitigate risks.
    • Incident management: The software provides tools to help businesses respond to and manage incidents related to third-party relationships, such as data breaches or compliance violations.

    Best Practices for Software Supply Chain Risk Management

    The following are some best practices for managing supply chain risks.

    Identifying Supply Chain Threats and Potential Weaknesses

    The first step in managing supply chain risks is to identify potential threats and vulnerabilities in the supply chain. This involves conducting a comprehensive risk assessment that considers all potential sources of risk, including geopolitical factors, natural disasters, cyber threats and other disruptions. The risk assessment should consider the entire supply chain, including all vendors, suppliers and partners.

    During the risk assessment, organizations should identify the critical components and services that are essential to their operations. They should also evaluate the potential impact of a disruption to these critical components and services, including the financial, reputational and operational impact.

    Establishing a Supply Chain Risk Management Framework

    After identifying potential threats and vulnerabilities, organizations should establish a supply chain risk management framework that outlines the policies, procedures and controls required to mitigate these risks. The risk management framework should be aligned with the organization’s overall risk management strategy and should include the following components:

    • Risk management policy: This policy should outline the organization’s approach to supply chain risk management and define the roles and responsibilities of key stakeholders.
    • Risk assessment procedures: These procedures should describe how the organization conducts risk assessments, including the criteria used to evaluate risks and the frequency of assessments.
    • Risk mitigation controls: These controls should outline the specific measures the organization will take to mitigate identified risks.
    • Incident response plan: This plan should describe the steps the organization will take in the event of a supply chain disruption.

    Continuously Monitoring Risks

    Once the supply chain risk management framework is in place, organizations should continuously monitor supply chain and third-party risks and take proactive measures to mitigate them. This includes establishing a patching cadence to ensure that all software components are up to date and protected against known vulnerabilities.

    Organizations should also implement endpoint security controls, such as antivirus software and intrusion detection systems, to protect against malware and other cyber threats. Network security controls, such as firewalls and access controls, should be implemented to protect against unauthorized access to systems and data.

    Web application security controls should also be implemented to protect against web-based attacks, such as SQL injection and cross-site scripting. This includes conducting regular vulnerability assessments and penetration testing of web applications.

    Promoting a Culture of Awareness

    Finally, organizations should promote a culture of awareness among all stakeholders, including employees, vendors, and suppliers. This includes providing risk awareness training to employees, so they understand the risks associated with the supply chain and the steps they can take to mitigate these risks.

    Organizations should also communicate their supply chain risk management policies clearly to vendors and suppliers so they understand their obligations and responsibilities in managing supply chain risks. This includes conducting due diligence on vendors and suppliers to ensure they meet security standards and policies.

    Conclusion

    Managing supply chain risks is a critical task for organizations that rely on third-party vendors and suppliers to deliver goods and services. These risks can arise from a range of sources, including geopolitical factors, natural disasters, cyber threats and other disruptions.

     To effectively manage these risks, organizations need to adopt best practices such as identifying threats and potential weaknesses, establishing a supply chain risk management framework, continuously monitoring risks and promoting a culture of awareness.

    As we look ahead to 2023, it is clear that software supply chain management will continue to be a priority for organizations across industries. With the increasing complexity of software supply chains and the evolving threat landscape, organizations must remain vigilant in their efforts to identify and mitigate potential risks.

  • How to Maximize Telemetry Data Value With Observability Pipelines

    How to Maximize Telemetry Data Value With Observability Pipelines

    The software landscape has shifted significantly in recent years as companies digitize their operations and adopt cloud and microservices technologies. The complexity of modern software systems has led to an increasing need for real-time visibility into their performance—resulting in an explosion of telemetry data that is stretching IT budgets and outpacing engineering teams’ ability to find value in that data. In fact, data volume is growing at 23% yearly, while IT budgets are only growing at 5%.

    Managing all this data at increasing cost is further compounded by unpredictable software failures and ever-evolving security threats. As a result, companies are forced to pick which parts of their software to instrument and monitor. To overcome this challenge, a different approach to managing data is required.

    Observability pipelines are emerging as a way to address this problem. They centralize telemetry data (i.e., logs, metrics and traces) from many sources, transform that data to fit downstream needs, and route it to various destinations for analysis. With complete control of the data, companies can sort through large amounts and prioritize what is essential, allowing them to act swiftly to avoid disruptions while reducing costs by only storing the data they need.

    Research indicates 62% of organizations currently have an observability practice. This means 38% operate with limited awareness of what’s happening in their software. Even those with an observability practice can only afford to store some data and have to choose which applications to instrument. This leads to blind spots and, ultimately, issues that are time-consuming to fix due to a lack of data.

    Managing Limited Resources With Observability Pipelines

    Engineers face more demands in today’s fast-paced business environment than ever before. Despite an increase in their responsibilities, the size of engineering teams has yet to grow accordingly. Given this, there has been a rise in full-stack engineers responsible for technologies from the front end to the back end. Short on time and resources, it’s difficult for these engineers to instrument and monitor software.

    Observability pipelines help control the amount of telemetry data using various processors such as sampling, throttling, filtering and parsing, and only forward valuable data to the downstream systems. The rest of the data can either be discarded or stored in a low-cost system, such as Amazon S3. This reduces costs and lets engineers focus on analyzing relevant data to identify issues.

    Engineers can also use observability pipelines to consolidate data from various tools. Many teams use different platforms or open source tools, like Prometheus or Jaeger. The fragmented data makes it hard to solve issues and understand application health. Observability pipelines combine all this data to make it easier to act on.

    It’s also important to remember that real people work on these technical challenges. Engineers face burnout working long hours to keep up with software development demands. Constantly switching between tools and manually moving data adds to the pressure. Moreover, the number of data sources, observability tools, and platforms that need that data are constantly increasing. Embracing open standards such as OpenTelemetry can ease this integration burden. Engineers can swap out tools without extensive testing and integration. The increased control and easy integration enable engineers to focus on delivering business value.

    Making Data More Usable

    Teams across organizations want access to data but struggle to use it effectively. The difficulty stems from the lack of data usability: Telemetry data is unstructured; varying formats make it hard to use; data preparation is time-consuming and sensitive data in logs may lead to compliance violations.

    By most estimates, 80%-90% of data is unstructured, which makes it hard to store and analyze because it doesn’t adhere to traditional data models. Observability pipelines make sense of unstructured data before it reaches its final destination. This is achieved using data processors that shape and transform data to make it more actionable. These processors include advanced parsers that identify and extract relevant information, transforming data into consumable formats that make it easier to work with and analyze.

    The advantage of performing these operations within the pipeline is that the same data can be prepared to fit different use cases downstream. For instance, while one team may require data optimized for visualization and trend analysis, another may require complete data for threat hunting. These transformations are managed from a single control point, eliminating the need to maintain separate data streams.

    Observability pipelines can also help companies meet data compliance requirements. For example, teams can scrub, mask or redact PII data based on a defined key structure before the data reaches a SIEM or audit platform.

    Taking Immediate Steps to Make the Most of Telemetry Data

    Organizations can take immediate action to make the most of their telemetry data. First, they need to adopt a visibility-first rather than a cost-first approach. They should assess what software they’ve instrumented. This will identify gaps in telemetry, which can be used to develop a plan to instrument all software. Next, they need to create a strategy for managing their telemetry data, being particularly thoughtful about how and why the data is stored and analyzed.

    Once a company has taken these two steps, it can decide which tools to use. One of the great things about OpenTelemetry is that it provides flexibility for future decisions about what tools to use.

    As companies invest more resources into building observability practices, they’ll encounter problems processing an extraordinary amount of telemetry data for any meaningful action. Observability pipelines provide a competitive advantage of prioritizing the essential data that will enable companies to make better decisions faster.

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