devopsy.kinsta.cloud

Tag: software security

  • Snyk Survey: AI Generating More Vulnerabilities in Code

    Snyk Survey: AI Generating More Vulnerabilities in Code

    A survey of 404 IT professionals conducted by Snyk found the use of artificial intelligence (AI) to write code is creating a security paradox. On one hand, just over three-quarters of respondents (77%) said AI tools improve code security. At the same time, however, 59% are concerned that AI tools trained using general-purpose large language models (LLMs) will introduce security vulnerabilities that first appeared in the code used to train them.

    The challenge with general-purpose LLMs is that they are trained using a combination of excellent, mediocre and flawed code. As a result, any recommendation surfaced has the potential to be a suboptimal security result.

    Randall Degges, head of developer relations for Snyk, said that as AI tools increase the velocity at which applications can be constructed, it’s probable that DevOps teams will discover more vulnerabilities in their code.

    In general, 61% of respondents also noted that automation has increased the number of false positives, with 62% of respondents reporting that at least one out of every four vulnerability alerts they received from automation tools were false positives. Well over a third (35%) said false positives represented over half of the vulnerability alerts.

    On the plus side, however, more organizations are paying closer attention to application security issues in the wake of several high-profile breaches of software supply chains and disclosures of vulnerabilities. A full 96% reported their organizations are addressing supply chain security problems on an ad hoc basis, yet only half have a formalized supply chain security strategy in place.

    The survey also finds 87% of respondents work for organizations impacted by a software supply chain security issue in the last year, with 61% having implemented new tools and processes as a result.

    A total of 62% of respondents work for organizations that have a software life cycle assurance process in place, but only 42% of organizations are using software bills of materials (SBOMs). In addition, only 40% have formal security ratings for the open source packages that developers employ, and 31% ignore risks that arise from indirect dependencies.

    However, only 40% of organizations have embedded security testing tools into their integrated development environments (IDEs), with 40% not using software composition analysis (SCA) or static application security testing (SAST) tools at all. In fact, even though 80% of respondents reported working for organizations that ship code daily, only 27% claim to continuously audit their code.

    As a result, many vulnerabilities remain unpatched, with Java (42%) and JavaScript (31%) topping the list in terms of code with the most ignored vulnerabilities.

    Finally, the survey also noted that vulnerabilities involving open source code are now being remediated faster than proprietary code. Maintainers of open source software are now paying more attention to cybersecurity issues thanks in part to the tools and best practices provided by the Open Source Security Foundation (OpenSSF), said Degges.

    There will, of course, come a day when AI is more widely used to analyze vulnerabilities in code. In effect, AI will be used to solve some of the security issues general-purpose LLMs create. In the meantime, however, DevSecOps teams would be well-advised to proceed with caution.

  • Extending the GitOps Pipeline: DevSecOps and Trusted Application Delivery

    Extending the GitOps Pipeline: DevSecOps and Trusted Application Delivery

    We live in a fast-paced world of rapid changes and uncertainty where every aspect of our daily lives changes often, including the way we work and communicate. Organizations must deliver value to their customers at a much faster pace than ever before to thrive in such an environment. However, the decentralized nature of cloud infrastructure expands the threat landscape and poses several security risks that enterprises should address in light of recent data breaches.

    Organizations must combat security threats and address challenges arising from cloud misconfigurations. Several recent tools, strategies, practices and technologies have emerged that can help you handle such security threats. This article discusses how the fusion of DevSecOps and trusted application delivery can extend the GitOps pipeline and add business value.

    What is GitOps?

    Coined by Weaveworks in 2017, GitOps thrives on a source code management system built on Git and adheres to the belief that Git is the single and definitive source of truth. Since all changes are stored in Git, anyone can see the audit trail if necessary. This enables you to use Git-based version control to manage your application’s code, environment and processes.

    Figure 1: CI/CD with Git-based Version Control

    GitOps leverages Git repositories as the one and only source of truth and embraces DevOps and infrastructure-as-code (IaC) best practices. Using GitOps, your developers can spend more time developing applications than configuring or maintaining Kubernetes clusters.

    GitOps strategies are gaining traction with enterprises for various reasons, including improved productivity, increased deployment frequency and improved security. While it’s true that GitOps continues to be a transformative trend, the increased speed and automation can also lead to misconfigurations that compromise application stability and security.

    Figure 2: CI/CD using GitOps

    Often, these security vulnerabilities delay development as developers spend significant time and effort investigating them. Since this poses a hindrance to progress, the question that arises is how enterprises can maintain the frequency and speed of deployment while remaining secure and reliable. This is where trusted delivery comes in.

    An Extension of DevOps

    DevOps is a software engineering practice and culture that blends development and operations to provide a shared and collaborative approach to developing and maintaining software. This can boost productivity, lower costs and increase customer value through increased collaboration.

    GitOps extends DevOps to bring the deployment workflow closer to developers. GitOps integrates code and configuration management for cloud-native application deployment and administration, while DevOps fosters shared ownership, transparency, and rapid feedback.

    GitOps uses DevOps-proven practices like version control, code review and CI/CD pipelines with any Git-based repository, including GitHub, GitLab or BitBucket. It builds on DevOps and applies DevOps best practices for infrastructure automation.

    What is Policy-as-Code?

    When deploying and managing cloud-native infrastructures, adhering to security best practices and regulatory standards is critical without hindering development. Policy-as-code is an approach to infrastructure security in which rules are codified and enforced, thereby reducing or eliminating human errors. You can use it to write applications using a high-level language to control, manage and automate policies. With policy-as-code in place, developers may create applications to manage security, compliance and other regulations seamlessly.

    Here are the types of policies that you can codify:

    • Security Policies: By adhering to these policies, you can protect your software from data breaches caused by misconfigurations.
    • Resilience Policies: The use of these policies in your Kubernetes clusters will help you create highly available, fault-tolerant systems as well as maintain business continuity.
    • Coding Standards Policies: These policies can enforce coding consistency, i.e., any code that violates these policies will be rejected automatically by the system.

    What is Trusted Application Delivery?

    Trusted delivery entails codifying security policies within your software delivery pipeline for security and compliance and introducing guardrails at every stage. By ensuring the security, integrity and reliability of your applications deployed in production environments, unauthorized access, tampering or malware introduction is minimized. It establishes and maintains trust in application source code, artifacts and deployment pipelines throughout the SDLC process.

    The key objectives of trusted application delivery are:

    • Security: It protects the application from security threats and vulnerabilities
    • Integrity: It verifies the authenticity and integrity of the source code of your application, together with the dependencies, and any artifacts
    • Reliability: It ensures that the applications deployed to the production are stable and are devoid of any security loopholes so that they can perform as desired

    Trusted application delivery helps development teams release applications early and secures them with automated protections or guardrails. It extends the GitOps pipeline by integrating security, governance and verification with policy-as-code. These security measures are implemented with policy-as-code. The policy-as-code approach encompasses the entire SDLC, including the design, development, testing and deployment stages.

    According to your organization’s security and compliance policies, compliance and security rules are codified and integrated into the system. Throughout the life cycle of your application, you can manage its security, compliance and other regulations using policy-as-code. These code-defined policies prohibit the provisioning of non-compliant resources. You should implement trusted application delivery practices to secure your organization’s application delivery process and reduce the likelihood of unauthorized access.

    Here are the key benefits of trusted delivery:

    • Faster and more frequent releases
    • Enhanced security
    • Protect against misconfigurations
    • Avoid compliance violations
    • Improved collaboration

    What is DevSecOps?

    DevSecOps is a software development methodology that blends development (Dev), security (Sec) and operations (Ops) at all phases of the SDLC by incorporating mandatory security checks. An organization of any size can benefit by creating a culture of shared responsibility and collaboration by bridging the gap between development, security and operations teams.

    A DevSecOps pipeline adds practices such as scanning, policy enforcement, static code analysis, threat intelligence and compliance validation to the SDLC process. Contrary to traditional software development processes that treat security as an afterthought leading to security vulnerabilities and breaches, DevSecOps is a paradigm shift that fosters a culture of proactive and continuous security approach to help address security concerns and vulnerabilities.

    DevSecOps and GitOps help organizations adapt quickly to changing emerging trends and requirements. DevSecOps is an offshoot of DevOps that focuses primarily on security throughout the development process. It helps detect and resolve security issues and vulnerabilities easily and quickly while fostering a culture of continuous improvement.

    Here are the benefits of DevSecOps at a glance:

    • At the outset, determine which points in the SDLC process are susceptible to security flaws and vulnerabilities in the SDLC process
    • Streamlined compliance
    • Secure supply chain
    • Reduced risk of the attack surface
    • Complete visibility of potential threats

    Why DevSecOps?

    DevSecOps is a proven way to secure your CI/CD pipelines, deliver secure, trusted, high-quality software and foster an environment where security is the responsibility of everyone in the organization. By shifting security left—i.e., introducing security into the CI/CD pipeline earlier—organizations can be much more productive and the teams can be more cooperative and collaborative.

    Given the threats to the security of the software supply chain, DevOps practices have given way to DevSecOps practices, where safety is paramount and a fundamental and ongoing component of software development. At the outset of the SDLC, you should ensure that software components and dependencies are secure to avoid potential software supply chain hazards.

    Additionally, it would help if you had built-in security gates in each step of the SDLC to ensure consistent, repeatable and automated processes from the software build phase to deployment. Remember, DevSecOps isn’t an option; instead, it is a necessity.

    Trusted Delivery With GitOps

    Automated software delivery pipelines are based on Git as the only source of truth. Policy-as-code is a great way to ensure that misconfigurations and errors are detected, alerted, and deployments halted automatically. Next, we’ll cover how a typical GitOps workflow determines where multiple checkpoints can be implemented for trusted delivery.

    In a typical workflow based on GitOps, a developer commits the source code to a Git repository. The CI tool then builds the container images. These container images are then tested and then uploaded to an image repository. At the end of this process, these container images will be deployed to a Kubernetes cluster. GitOps agents compare the current cluster state with the desired state on a continuous basis.

    Hence, you should implement security guardrails at the following points:

    • Git repository
    • CI stage
    • Configuration repository
    • Kubernetes cluster

    Creating a Trusted Software Supply Chain With DevSecOps

    You can build a trusted software supply chain by incorporating security practices throughout the SDLC to ensure the integrity and security of the software delivered by DevSecOps. Here is a step-by-step guide to building a trusted software supply chain by leveraging DevSecOps principles:

    • Security by Design: You should integrate security right from the outset of the SDLC and identify the key threats to the security of the pipeline.
    • Application Dependency Scanning: When building applications, we often use third-party dependencies to accelerate the development process. You should monitor security vulnerabilities and patches as they become available for these dependencies. You can leverage OWASP Dependency Check, Firewall from Sonatype, etc.
    • Secure Coding Practices: You should adhere to and enforce these practices among your development teams. You can integrate static code analysis tools into your DevSecOps pipeline, conduct regular code reviews and identify and fix security issues.
    • Container Security: You should scan container images regularly for security vulnerabilities, implement strategies to secure your containers and use container registries with access controls.
    • Continuous Compliance: You should ensure the software supply chain adheres to the relevant standards and guidelines for compliance requirements. In this regard, you should conduct audits regularly to check if compliance requirements have been satisfied.
    • Collaboration and Communication: You should be able to foster a culture in your organization that facilitates collaboration and communication across the development, operations and security teams.

    DevOps, DevSecOps and GitOps: The Future

    As organizations strive to optimize the efficiency of their software supply chain, DevOps, DevSecOps and GitOps are approaches that can improve collaboration, efficiency and security, to help software developers and IT operations succeed. These practices would become more critical and widely used in the future. GitOps provides teams with better tools for managing configurations so they can focus on more strategic activities.

    While GitOps is an approach that advocates Git-based version control systems as the single source of truth, DevOps is concerned about a cross-functional team that can work together. DevSecOps goes a step further by blending security into all stages of the SDLC process.

    The future of DevOps, DevSecOps and GitOps will see increased automation, tighter security integration and a sustained emphasis on efficiency and collaboration. Your organization should adopt these approaches to provide reliable software and services to its customers.

    Conclusion

    Trusted application delivery is essential for securing applications, protecting user data, meeting compliance requirements and preserving market credibility and trust. It helps enterprises and end consumers by ensuring that software is distributed securely and reliably. Organizations can ship high-quality applications with guaranteed security and performance by adopting trusted delivery practices.

  • JFrog Adds Curation Capability for Open Source Software Components

    JFrog Adds Curation Capability for Open Source Software Components

    JFrog today announced it is adding a curation capability for open source software to its portfolio that will use metadata generated by binaries to identify malicious packages and software components that have licensing issues.

    Sharan Hiremath, senior product manager for JFrog, said JFrog Curation is an extension of the JFrog Artifactory binary repository that the company provides to enable organizations to manage their software supply chains.

    JFrog Curation also validates software packages against JFrog’s Security Research library of recorded Critical Vulnerabilities and Exposures (CVEs) and publicly available information to help establish a trusted repository of pre-approved, third-party software components.

    That approach automatically employs the JFrog Xray scanning tool to eliminate the need to individually scan each package before developers employ them, said Hiremath.

    Making sure open source software components are secure is often problematic because developers download them from public repositories that are frequently targeted by cybercriminals. There have now been more than 100,000 instances of malicious software packages discovered in repositories in the last year alone, noted Hiremath.

    In addition, cybercriminals have become adept at creating fake repositories that mimic legitimate repositories; that can result in developers downloading software components infected with malware.

    JFrog Curation takes the shift left concept of application security to the next level by automatically blocking the use of risky open source software packages, noted Hiremath. The JFrog platform will also surface advice on how to remediate any vulnerability discovered, in addition to creating an audit trail to enable organizations to comply with various regulatory mandates.

    While open source software components reduce the cost of application development, from a cybersecurity perspective, it’s the wild, wild West, noted Hiremath. Organizations are trying to bring more discipline to the way software is constructed by adopting DevSecOps best practices, but they need an approach that doesn’t introduce any additional friction into the application development process, he added.

    JFrog Curation addresses that issue by addressing cybersecurity and compliance issues before any open source component becomes part of the build, said Hiremath.

    As regulations to hold organizations more accountable for the security of the software they deploy are being proposed around the world, it’s only a matter of time before organizations must revisit the security of their software supply chains. Cybercriminals have already proven how adept they are at injecting malware into software components that could be used in thousands of downstream applications. In the eyes of regulators, organizations that don’t scan open source software for malware and vulnerabilities are engaging in reckless behavior that will warrant stiff penalties.

    The challenge is that, after giving developers free rein to develop software any way they see fit, organizations are now faced with a challenge that is as much cultural as it is technical. Automated processes will naturally play a key role in curbing aberrant behavior in application development, but there is, as always, no substitute for some good old-fashioned common sense.

  • Unleashing the Power of AI-Engineered DevSecOps

    Unleashing the Power of AI-Engineered DevSecOps

    In my recent article Revolutionizing the Nine Pillars of DevOps with AI-Engineered Tools, I explained that AI-engineered tools can help implement the portion of continuous security practices known as DevSecOps.

    DevSecOps involves integrating security practices into the DevOps workflow. AI can be used in anomaly detection to identify potential security threats and to automate security policy enforcement. AI-engineered tools have the potential to significantly enhance security across all phases of the software value stream in DevSecOps.

    Planning: The planning stage involves dealing with complexities related to risk analysis and threat modeling. AI can help automate risk analysis and threat modeling based on data from past projects and known security issues. This can help identify potential security threats early in the planning phase and develop appropriate mitigation strategies.

    Design and Development (prior to integration): Developers often face difficulties in writing secure code, identifying potential security vulnerabilities, and adhering to best security practices while coding. AI-powered static application security testing (SAST) tools can automatically scan the source code for known vulnerabilities and coding errors, providing immediate feedback to developers. In addition, AI could be used to generate recommendations for secure coding practices and strategies for mitigating identified vulnerabilities.

    Continuous Integration (CI): Continuously integrating new code can introduce new security vulnerabilities and regression bugs that are hard to catch and fix in a timely manner. AI can be utilized in dynamic and interactive application security testing tools (DAST and IAST) during the integration stage. They can intelligently automate tests and identify complex security issues by analyzing data flows and the behavior of code in an integrated environment.

    Continuous Delivery (CD): Ensuring that the code is not only functional but also secure before it is delivered is a major challenge. AI-powered tools can help manage security configurations, monitor changes and alert to any deviations from security policies during the delivery stage. AI can also be used to automate security testing in pre-production environments to ensure that security standards are met before delivery.

    Continuous Deployment (to production): Monitoring, detecting and responding to security threats in real-time in production environments is a critical and challenging aspect. AI can enhance security information and event management (SIEM) tools by providing intelligent real-time analysis of security alerts generated by applications and network hardware. AI-based runtime application self-protection (RASP) tools can also detect and block attacks in real-time, providing robust protection for applications in production.

    Roadmap to AI-Engineered DevSecOps

    It’s crucial to implement AI-engineered DevSecOps solutions in a structured and well-planned manner. Here is a logical roadmap for implementing such a solution:

    1. Assessment and Planning: Begin by assessing your organization’s current DevSecOps maturity. Evaluate the existing tools and practices for their efficiency and effectiveness. Identify areas that lack automation or present security concerns. Align the AI-engineered DevSecOps initiative with your business objectives. This includes defining key performance indicators (KPIs) to measure the success of the initiative. Outline the required resources and budget for the implementation. This includes potential AI-engineered tools, the team’s skills upgrading needs and additional infrastructural changes.

    2. Selection of AI-Engineered Tools: Based on your assessment, select the AI-engineered tools that best fit your organization’s needs. This selection should cover the entire software development life cycle: Planning, design and development, continuous integration, continuous delivery and continuous deployment. The tools should ideally be scalable, easy to integrate with your existing systems and capable of providing real-time, actionable insights to your team.

    3. Training and Upskilling: Train your team on the selected AI-engineered DevSecOps tools. This may require technical training on how to use the tools effectively and how to interpret the insights generated by the AI. Upskill your team to enable them to work effectively within the new AI-engineered DevSecOps environment. This could involve training in AI and machine learning, security best practices and new DevSecOps methodologies.

    4. Gradual Implementation and Integration: Start with pilot projects to validate and tweak your approach. The lessons learned from these initial projects will be valuable for the broader roll-out. Gradually implement and integrate the selected AI-engineered tools into your existing DevSecOps pipeline. This should be a phased approach that allows your team to adapt to the new tools and practices.

    5. Review and Refinement: Regularly review the effectiveness of your AI-engineered DevSecOps implementation against the defined KPIs. Continuously refine your approach based on these reviews. This could involve adjusting your security policies, refining how you use your AI tools or providing further training to your team.

    6. Continuous Improvement: Keep yourself updated with the latest developments in AI and DevSecOps to ensure your approach remains effective and up-to-date. Continually improve and evolve your AI-engineered DevSecOps solution based on emerging technologies, shifting business objectives and feedback from your team.

    Avoiding Pitfalls While Implementing AI-Engineered DevSecOps

    Implementing an AI-engineered DevSecOps solution comes with several potential pitfalls that can derail the process if not appropriately managed. Here are a few of them, along with suggestions for how to avoid them:

    1. Inadequate Planning and Alignment with Business Goals: Ignoring the strategic alignment between implementing AI-engineered DevSecOps and overall business goals can lead to undesirable outcomes. Clearly define the business objectives and how AI-engineered DevSecOps supports them. Outline expected outcomes and key performance indicators (KPIs) that align with business goals to guide the initiative.

    2. Neglecting Training and Upskilling: AI tools can be complex, and without proper understanding and training, their deployment may not yield desired results. Invest in training your teams on AI-engineered DevSecOps tools and techniques. Ensure they understand the functionalities of these tools and how to effectively use them. Upskilling your team will be crucial for leveraging AI capabilities.

    3. Ignoring Change Management: Introducing AI into DevSecOps is a significant change that can disrupt workflows and resistance from the team members. Adopt a systematic approach to change management. Engage stakeholders from the beginning, communicate the benefits of the transformation clearly, and encourage feedback. Also, plan for a gradual rollout to help teams adapt.

    4. Overdependence on AI: Relying too heavily on AI can be a risk if the tools are seen as a complete replacement for human judgment. Recognize that AI is a tool designed to assist human decision-making, not replace it. It’s important to maintain human oversight of AI outputs, as AI models might not fully account for all contextual and situational factors.

    5. Neglecting Data Privacy and Ethical Considerations: Using AI requires handling a lot of data, which can lead to privacy breaches and ethical dilemmas if not handled correctly. Develop a clear policy for data management, ensuring compliance with all relevant data privacy laws and regulations. Make ethical considerations a priority when implementing AI, ensuring transparency and fairness in the AI systems.

    6. Lack of Continual Improvement and Adaptability: AI-engineered DevSecOps requires a culture of continuous learning and adaptation. Failure to embrace this can lead to stagnation and ineffectiveness over time. Establish a framework for continual improvement. Regularly evaluate the effectiveness of the AI tools and be ready to adapt your processes based on new technological advancements, feedback, and changes in business needs.

    Summary

    Implementing an AI-engineered DevSecOps solution necessitates a thorough and strategic approach. This begins with an in-depth assessment of your organization’s current DevSecOps maturity and an understanding of how AI can enhance each phase of the software value stream. Essential steps in the roadmap include tool selection, team training, gradual implementation, regular review and continuous refinement and learning. While AI can significantly bolster security and efficiency, it’s important to avoid pitfalls like inadequate planning, neglecting training, resisting change, overdependence on AI, neglecting data privacy and ethical issues and lack of continuous improvement. By focusing on these areas, aligning the DevSecOps initiative with business objectives, investing in team upskilling, managing change effectively, maintaining human oversight, adhering to data privacy regulations and fostering a culture of continuous learning, organizations can successfully implement and maximize the benefits of AI-engineered DevSecOps.

    Remember, this transformation won’t happen overnight. It is a continuous journey that requires regular review and improvement. With the right strategy, the benefits of implementing an AI-engineered DevSecOps solution can far outweigh the challenges.

  • Atlassian Advances DevSecOps via Jira Integrations

    Atlassian Advances DevSecOps via Jira Integrations

    Atlassian announced today it has allied with Snyk, Mend, Lacework, Stackhawk and JFrog to make it simpler to aggregate vulnerability data within the Jira project management software that many organizations rely on to manage application development and deployment efforts.

    Andrew Pankevicius, a senior product manager for Atlassian, said the collaborations will make it easier to prioritize a list of vulnerabilities that need to be addressed and for DevOps teams to automatically assign that work to a continuous integration/continuous delivery (CI/CD) pipeline. Atlassian provides those third-party integrations via an Open DevOps initiative.

    These capabilities, accessible via the Security Tab in Jira, will make it simpler for DevOps teams to manage output from the multiple application security tools that have become part of a larger DevSecOps workflow, noted Pankevicius.

    These additions to the Atlassian portfolio are arriving at a time when there is a lot more focus on securing software supply chains in the wake of a series of high-profile breaches. Those breaches have led to a wave of legislative proposals in the U.S. and Europe that will soon require organizations to embrace DevOps best practices to address increased potential liability that might stem from an application breach.

    For example, a proposed Cyber Resilience Act being negotiated by the member states of the European Union seeks to require organizations that sell internet-connected hardware platforms to ensure that their devices—and the software that runs on them—comply with cybersecurity best practices.

    In the U.S., meanwhile, a National Cybersecurity Strategy proposal put forward by the Biden administration seeks to hold organizations that collect data or build software more accountable for breaches.

    While both proposals are a long way from becoming the law of the land anytime soon, they are indicative of changing attitudes. Governments around the world are concluding the only way to ensure better cybersecurity is to require it. Previous suggestions made by government agencies are going to soon give way to actual mandates. As such, DevOps teams would be well-advised to get ahead of this sea change by implementing the tools and processes that inevitably will be required. As a result, many organizations are now embracing DevSecOps best practices that shift more responsibility for application security further left toward developers.

    The challenge is finding the right set of cybersecurity tools that surface vulnerabilities as code is being developed to make sure context isn’t lost, said Pankevicius. Historically, cybersecurity teams have discovered vulnerabilities long after an application has been deployed in a production environment. By then, however, most developers have moved on to other projects, so remembering how a specific piece of code was developed and by whom can be a significant challenge, he noted.

    There’s no doubt that when it comes to application security, a lot of progress has been made, but there is still much work to be done. The issue now is finding the best way to organize those efforts at a time when more applications are being simultaneously developed within organizations than ever.

  • How DevSecOps Addresses Supply Chain Security

    How DevSecOps Addresses Supply Chain Security

    “The absence of security in the initial stages of system engineering is the single most significant cybersecurity gap and risk in modern system development.” This quote from tech entrepreneur Linda Rawson is a good reminder for the current cybersecurity threat situation. With software supply chain attacks increasing in aggressiveness and sophistication, organizations need to understand that cybersecurity should no longer be an additional process, let alone an afterthought.

    Integrating security in the software development process provides a few other benefits, including better efficiency and customer satisfaction. However, its most notable benefit is addressing cybersecurity threats more effectively compared to the conventional ways of enabling software security.

    The Rise of DevSecOps

    DevSecOps is a fast-rising star in today’s search for effective cybersecurity solutions. The DevSecOps market is expected to be worth $23.63 billion in 2030, growing at a CAGR of 23.84% in the forecast period 2023-2030. Its value in 2022 was estimated at around $4.27 billion.

    This double-digit growth is actually a bit conservative. Other forecasts showed higher CAGRs in the 30% range. This growth hints at the strong demand for DevSecOps solutions. Many organizations have started to acknowledge the benefits of implementing security validation methods early in the software development life cycle (SDLC) instead of doing them in bulk as a separate phase at the end of the development process.

    Many organizations are now convinced that they can benefit from shifting left or bringing security into the SDLC earlier. Tools and solutions like static code analysis (SCA), automated dynamic analysis, interactive application security testing (IAST) and source composition analysis address security weaknesses before an application is released to the market. This allows organizations to release apps faster and, because of the elimination of most bugs and vulnerabilities, provide considerably better user experiences.

    Vulnerabilities will never be completely eliminated, but they can be significantly reduced and more properly resolved while software is being developed if security validation is integrated in the development process. Some software defects and weaknesses tend to be more difficult to address through a separate security testing process, since it would entail a broader code tracing or review as opposed to quickly spotting the affected code when security validation is done alongside the development process.

    Addressing Software Supply Chain Attacks

    So, how does DevSecOps help prevent supply chain attacks? The key is in the visibility and control DevSecOps affords.

    DevSecOps requires vigilance of security issues throughout the software development process. Security is not relegated to a different team that doesn’t understand the specifics of a development project. As such, the team has broad visibility over security concerns. Because the DevSecOps team also has mastery of the code being developed, it is easy to trace the origin of vulnerabilities and implement the necessary corrections.

    DevSecOps is aided by automated tools that scan code for security issues and detect threats even before they manifest themselves as problems. These tools are used across all phases of the development process, from the time code bears basic features and functions to deployment and post-production.

    Static testing: Even before an application’s code is ready to run, it can be subjected to static testing to find vulnerabilities. Tools such as static application security testing (SAST) can analyze code and detect possible security problems.

    How does this address software supply chain attacks? Static testing can be overlaid on automated CI/CD pipelines to stop code that has security weaknesses from getting committed to the codebase.

    Dynamic testing: An automated dynamic analysis can be used for code that is already executable. This is done through dynamic application security testing (DAST) tools, which are capable of detecting vulnerabilities usually invisible to SAST but which are detectable once the code is running.

    How does this address software supply chain attacks? Organizations can implement automated black-box testing for apps in the CI/CD pipeline(s) to detect security flaws for apps that are already executable. This addresses the vulnerabilities that have not been detected by static testing while reducing the costs associated with the corresponding remediation.

    Interactive app testing: This is a combination of static and dynamic testing. It employs IAST tools which run static testing on available code and come up with bespoke dynamic tests for a specific app to identify issues more thoroughly.

    How does this address software supply chain attacks? Pure static and dynamic testing usually apply to earlier stages of the development process, whereas interactive testing addresses vulnerabilities that emerge in the later parts. By bringing IAST to the CI/CD pipeline, organizations achieve better security issue detection outcomes, which means the prevention of malicious code deployment.

    Supply chain analysis: This entails the use of tools that specifically examine the security of third-party libraries and dependencies. To be clear, this is not the only method for addressing software supply chain vulnerabilities. In this case, supply chain merely refers to the external libraries, dependencies and other components that do not originate from the development team.

    How does this address software supply chain attacks? Integrating software chain analysis tools in the CI/CD pipeline significantly reduces the adverse effects of vulnerabilities in dependencies and other components on a project’s codebase as well as on the development process itself.

    Security-as-Code

    One of the best practices developed in line with the integration of security in the software development process is the idea of implementing security-as-code. This means that security policies and measures such as testing and validation are turned into code whenever possible. In other words, the code itself already bears security mechanisms. Security testing runs automatically whenever code is committed. This ensures robust, consistent, highly scalable security that does not rely on external rules and mechanisms to prevent the introduction of anomalous code or malicious inputs.

    Security-as-code also means that the DevSecOps team can see how modifications to code and the underlying infrastructure are created. The team can map out the impact of code changes and identify the areas where security tests and regulations can be implemented to optimize processes and avoid unnecessary delays.

    Security-as-code is essentially the automation of security practices. It is not applicable in all instances, though, so it is still important to be knowledgeable about security testing methods that can be used in different stages of the development process.

    Securing the Software Supply Chain

    The SUNBURST incident and other similar high-profile attacks should serve as a warning for all organizations to ascertain the security of their software supply chain. DevSecOps is one of the best solutions right now. It does not guarantee the complete elimination of all threats, but it ensures that if threat actors succeed in getting around security controls, a breach won’t go unnoticed.

     

  • Report: Most IT Teams Can’t Fix Open Source Software Security

    Report: Most IT Teams Can’t Fix Open Source Software Security

    Lineaje, a provider of a platform for securing software supply chains, today published an analysis of 41,989 open source components embedded in the top 44 popular projects managed by the Apache Software Foundation (ASF). That analysis found more than a quarter (26%) of vulnerabilities are not patchable by the application development team that deployed them.

    In addition, the report found that 64% of the vulnerabilities analyzed have no patch as of yet. Overall, 68% of the vulnerabilities analyzed are due to dependencies created when an open source software project included a component or package developed by another open source project maintainer.

    Lineaje CEO Javed Hasan said that means that 90% of open source dependencies are transitive, in the sense that they are created when maintainers of a project included a vulnerable open source component created by another entity. Only 10% of the vulnerabilities discovered by Lineaje are the result of a dependency that an application development team could actually address on their own, he added.

    Overall, the report found a full 82% of components that are relied on to build open source software are inherently risky due to vulnerabilities, security issues, code quality or maintainability concerns. In addition, 5% of components failed a basic integrity check, with 3% having no known origin.

    Open source software is not created equal no matter what consortium is overseeing its development, noted Hasan. Unfortunately, there is no universally accepted method for validating the integrity of open source software, so application development teams should proceed with caution whenever employing open source software, he said.

    The challenge, of course, is that developers have been reusing open source software within applications for years now. It’s only in the recent wake of breaches involving open source software that organizations have been taking a harder look at how applications are developed.

    The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is now at the forefront of an effort to better secure open source software by focusing on 10 streams of investment that, in total, will require more than $150 million in funding to drive greater adoption of DevSecOps best practices among maintainers of open source software projects. The issue is that many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited. The onus for making sure open source software is secure when deployed in a production environment belongs to the organization that deploys it.

    Hopefully, following a recent executive order issued by the Biden administration, the level of open source security will steadily improve in the months ahead—assuming, of course, the organizations that rely heavily on open source software make more substantive contributions to securing it. In the meantime, organizations can count on the fact that cybercriminals have taken note of the vulnerabilities in applications that can be traced back to flaws in a wide range of open source software.

  • New Relic Bolsters Observability Platform

    New Relic Bolsters Observability Platform

    New Relic has updated its observability platform to include the ability to better detect and track errors in addition to monitoring vulnerabilities.

    At the same time, an instance of the New Relic observability platform that runs natively on the Microsoft Azure cloud platform is now also generally available.

    Manav Khurana, general manager for observability product and chief growth office for New Relic, said the alliance will enable Microsoft Azure customers to consume New Relic as part of their existing Microsoft Azure services contract.

    New Relic already provides an errors inbox to track issues, but is now adding a tool to track the impact an error might have by correlating data across traces and logs. The company has also integrated its platform with Slack to make it simpler for IT teams to generate alerts when vulnerabilities are introduced into codebases and manage errors more collaboratively.

    Similarly, New Relic is also looking to foster greater collaboration between software engineering and cybersecurity teams. A New Relic Vulnerability Management tool with no additional configuration required captures security signals generated via the company’s Telemetry Data Platform in a way that can be analyzed using an interactive application security testing (IAST) tool that New Relic gained with its acquisition of K2 Cyber Security. Additional IAST capabilities available in preview include the ability to leverage a patented deterministic technique to identify and provide automated vulnerability validation that highlights a proof-of-exploit.

    The overall goal is to provide more visibility and context for organizations that are implementing best DevSecOps practices, said Khurana.

    It’s still relatively early days as far as the integration of observability platforms into DevOps workflows is concerned. A recent survey conducted by New Relic found most organizations don’t expect to have robust observability practices in place by 2025. While most organizations have tools to monitor predefined metrics today, there is a significant gap between observability platforms that enable IT teams to determine the root cause of an IT issue and monitoring platforms that generate an alert whenever a threshold is exceeded.

    In fact, many organizations have too many monitoring tools that often surface conflicting or redundant alerts, noted Khurana.

    One way or another, more codebases are being instrumented. As that process continues to evolve, the agents embedded in that code make it simpler to collect the logs and traces needed to advance observability. The challenge, as always, is that it takes time for the number of fully instrumented applications to exceed the number of legacy applications that are either partially instrumented or not instrumented at all.

    As IT environments become more complex, the need for observability is becoming much more pressing at a time when most IT teams are more short-handed than ever, noted Khurana.

    Regardless of approach, there’s no doubt that observability, with patience, will impact the management of IT for the better.

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

  • Standardizing Federal Cybersecurity With DevSecOps

    Standardizing Federal Cybersecurity With DevSecOps

    DevSecOps is having a moment in the federal government. With President Biden’s Executive Order on Improving the Nation’s Cybersecurity and federal agencies’ issuance of DevSecOps best practices based on the Enduring Security Framework, government organizations are shoring up and standardizing their DevSecOps processes to meet today’s cybersecurity challenges head-on.

    Integrating security into the development process is particularly important for federal agencies that have invested significant time, effort and money in creating and running software development factories. These agencies are actively trying to balance security and innovation–and many are succeeding. The United States Air Force’s Kessel Run program is an example of a tightly run and innovative software factory.

    The question is: How can they continue this success as the calls for standardized cybersecurity grow increasingly louder?

    The Delicate Balance Between Security and Innovation

    It’s tough to balance security and innovation and wrap them both in a standardized process. It’s certainly not impossible, as Kessel Run proves. But it does require a high level of rigor to ensure that applications are being developed at speed while taking the necessary time to mitigate and minimize security risks and vulnerabilities. 

    Projects like Kessel Run and others work well in part because they bake security into the development process from the outset. That core tenet of DevSecOps allows teams to integrate and standardize security throughout their development cycles without losing momentum. 

    But, there are challenges to these standardization efforts that are inhibiting DevSecOps practices. 

    First, many government agencies are still working with legacy systems and toolsets rather than the modern technologies that many commercial companies that employ DevSecOps have access to. These technologies can include everything from collaboration platforms, to messaging applications, to underlying platforms that tie all the work being done together. 

    Second, despite the government’s commitment to innovation, old ways of thinking still persist in many pockets of the public sector. Some important people still think, “Why change when email has worked just fine for all these years?” Those people fail to immediately see the value of modernizing their toolsets and practices.

    But outdated technologies and processes won’t help government agencies balance security and innovation–and they won’t work with new cybersecurity policies and mandates. For instance, president Biden’s EO is filled with allusions to ensuring visibility into software development practices and the software supply chain. Doing both requires developers, security managers and operations managers to be on the same page and in constant communication at all levels of the development cycle. 

    Maintaining Situational Awareness Throughout the DevSecOps Process

    Yet even in the most mature DevSecOps environments, this isn’t always possible. Because while DevSecOps is driven by collaboration, that doesn’t mean that developers, security managers, and operations managers always know who’s working on what, or what the status of a particular project is at all times. This is particularly true in a government setting where old processes, technologies, and siloed teams are still present.

    But maintaining the balance between security and innovation is highly dependent on being able to have unfettered situational awareness throughout the development lifecycle. For example, a developer needs to know if a security operations teammate is working on fixing a vulnerability the developer discovered during testing. Likewise, an operations manager needs to know the status of the patch, as that might impact other factors important to the development process, including time to deployment.

    High-level dashboards help all team members quickly ascertain the status of projects in development and are useful in helping individuals understand where things exist in the pipeline. They can provide a quick, at-a-glance take that leaders can use to plan their projects, discover backlogs or potential roadblocks to deployment, and more.

    But even dashboards are not necessarily enough, because stakeholders need to be able to quickly and securely communicate status updates to each other.

    Collecting Communications, Facilitating Collaboration

    The problem is that not all of these individuals will necessarily be using the same tools. Some might be using one messaging service. Others might be holding impromptu video meetings. Others might be posting updates to project management boards. Software development is a living and agile process, and communication is happening all the time through different channels.

    That’s why it’s critical for agencies to pull all of these disparate threads together, especially if they are to properly manage security and maintain compliance with the EO. A single missed communication about a software vulnerability could end up becoming tomorrow’s SUNBURST attack. There must be a way for all DevSecOps stakeholders to interact with each other, regardless of their choice of tools or the channels they’re using.

    This is where the choice of modern toolsets and platforms comes into play. Pulling disparate threads together to facilitate better communication and collaboration requires technologies with the ability to connect various services, automate task management and alerts, and break down any lingering communication silos. It requires an underlying architecture that connects all key stakeholders so they can collaborate and ensure the security of the applications they’re working on. 

    Meeting the Cybersecurity Moment

    Older technologies and practices aren’t up to the moment government agencies are facing. They are unsuitable for today’s software development processes, and will not aid in the quest to stay ahead of today’s cyber threats.

    To meet the moment, government agencies must embrace new ways of communicating and collaborating. They must use the tools that are available to keep innovating even while standardizing according to cybersecurity regulations. They must provide their DevSecOps teams with the ability to work freely yet securely and set them up for success.