devopsy.kinsta.cloud

Tag: devsecops

Vulnerability Management for DevOps Teams: A Practical Guide

Vulnerability management is a process that includes the identification, categorization, prioritization and resolution of security vulnerabilities in software systems. It involves a continuous cycle of protection to ensure that your digital assets are secure and your operations are running smoothly.

With the rapid evolution of technology, fast-moving cloud-native systems and evolving cyber threats, it’s critical to stay ahead of the game. The goal is to close the gap between the discovery of vulnerabilities and their resolution, thereby minimizing the window of opportunity for potential attacks.

Vulnerability management is not just about finding and fixing vulnerabilities. It’s also about understanding the nature of the vulnerabilities and the potential impact they could have on your network and systems. This understanding informs the prioritization process, helping teams decide which vulnerabilities need immediate attention and which ones can be addressed later. See this blog post for an in-depth review of vulnerability management.

Why is Vulnerability Management Important for DevOps Teams?

With the DevOps approach, development and operations teams work together throughout the software life cycle. This collaboration results in faster development times and more reliable software. However, the fast development cycle also introduces new security challenges. This has given rise to the DevSecOps paradigm, where developers, operations teams, and security experts collaborate during all stages of the development lifecycle.

Here are a few reasons vulnerability management is a critical part of DevSecOps practices:

Early Detection of Vulnerabilities

DevOps teams are under constant pressure to deliver high-quality software quickly. However, the speed of delivery should not compromise the security of the software. Vulnerability management helps DevOps teams identify vulnerabilities early in the development process. This early detection allows teams to address security issues before they become serious problems.

Early vulnerability detection is not just about finding vulnerabilities; it’s also about understanding the potential impact of those vulnerabilities. It involves analyzing the vulnerabilities to determine their severity and the risk they pose to the system. This analysis informs the prioritization process, ensuring that the most critical issues are addressed first.

Building Continuous Security Into CI/CD Pipelines

Integrating vulnerability management directly into continuous integration/continuous deployment (CI/CD) pipelines is essential for maintaining continuous security. CI/CD pipelines automate the steps in software delivery, from code integration to deployment, ensuring faster and more consistent releases. By embedding vulnerability management into these pipelines, DevOps teams can automatically scan for and address security vulnerabilities at each stage of the software development life cycle.

Incorporating vulnerability management tools into CI/CD pipelines allows for automatic scanning of code repositories, container images, and even infrastructure-as-code (IaC) configurations for known vulnerabilities. This integration means that any security issues are identified as soon as code is committed or containers are built, not just at the deployment stage. The advantage of this approach is twofold: It reduces the risk of deploying vulnerable software, and it allows developers to fix issues in their context of development, making the process more efficient.

Cost-Effective Development and Operations

Implementing vulnerability management can lead to cost savings for DevOps teams. By identifying and resolving vulnerabilities early in the development process, teams can avoid the high costs associated with fixing security issues after the software has been deployed. In addition, vulnerability management can help prevent costly security breaches that could damage the company’s reputation and result in financial loss.

Moreover, vulnerability management can contribute to more efficient operations. By systematically managing vulnerabilities, teams can avoid wasting time and resources on low-priority issues. Instead, they can focus their efforts on addressing the most critical vulnerabilities.

Enhancing Cross-Team Collaboration

Vulnerability management can also enhance cross-team collaboration within the DevOps environment and between DevOps and security teams. By providing a clear framework for identifying, categorizing, prioritizing and resolving vulnerabilities, it fosters a shared understanding of security issues among team members. This shared understanding can facilitate communication and cooperation, ultimately improving the software product’s security posture.

Strategies for Integrating Vulnerability Management Into DevOps Processes

Adopt a ‘Shift-Left’ Approach

The ‘shift-left’ approach is a strategy that involves shifting the security measures to the early stages of the DevOps pipeline. Traditionally, security checks and vulnerability assessments were conducted toward the end of the development cycle, often leading to late discovery of security flaws and vulnerabilities.

By shifting these security measures to the left, i.e., to the earlier stages of the development cycle, DevOps teams can catch and fix security vulnerabilities early on. This approach aligns well with the DevOps philosophy of early error detection and continuous improvement.

Automation of Vulnerability Scanning and Detection

Automation is at the heart of DevOps. It allows for rapid, reliable and consistent processes, freeing up the team to focus on what they do best – delivering quality code and features. Automation should also extend to vulnerability management.

Automating vulnerability scanning and detection means integrating security tools into the DevOps pipeline that can automatically scan the code, detect vulnerabilities and even suggest fixes. This approach ensures that security checks are not skipped or forgotten and that vulnerabilities are dealt with promptly.

Security as Code

Another strategy for integrating vulnerability management into DevOps processes is embracing the principle of security-as-code. This principle treats security infrastructure and configurations as code, allowing them to be part of the DevOps pipeline.

By adopting security-as-code, DevOps teams can ensure that the security configurations and infrastructure are always up-to-date and follow the best practices. Like the rest of the code, security configurations can be version-controlled, reviewed, tested and automatically deployed.

Collaboration Between Security and DevOps Teams

One of the key tenets of DevOps is collaboration between different teams. In a DevSecOps paradigm, this collaboration extends to the security team as well. Integrating vulnerability management into DevOps processes fosters close collaboration between the security and DevOps teams.

The security team can provide valuable insights into the security landscape, vulnerability management tools and best practices. On the other hand, the DevOps team can ensure that these insights and tools are integrated into the DevOps pipeline.

Continuous Monitoring and Feedback Loop

Continuous monitoring is crucial for effective vulnerability management. Continuous monitoring ensures that the security state of the system is always known and that any changes or vulnerabilities are promptly detected. The feedback loop ensures that the insights gained from monitoring and vulnerability assessments are fed back into the development process, leading to continuous improvement in security.

Regular Training and Awareness

Finally, regular training and awareness are crucial for integrating vulnerability management into DevOps processes. DevOps teams should be trained in security best practices, threat landscape, and use of vulnerability management tools.

Regular training ensures that the team stays up-to-date with the latest security trends and vulnerabilities. Awareness sessions can help the team understand the importance of security and vulnerability management, encouraging them to take an active role in securing the system.

Conclusion

In conclusion, integrating vulnerability management into DevOps processes is not only possible but crucial for secure and reliable systems. Adopting a shift-left approach, automating vulnerability scanning and detection, embracing security-as-code, fostering collaboration, implementing continuous monitoring and feedback and ensuring regular training and awareness are some of the strategies that can help achieve this integration.

Remember, vulnerability management is an ongoing process that requires commitment, collaboration and continuous improvement.

December 7, 2023
Synopsys Report Sees Steady Application Security Gains

An analysis of the security automation practices of 130 organizations published today by Synopsys suggests significant progress has been made toward securing software supply chains in the last year. However, much work still remains to be done.

The annual Building Security In Maturity Model (BSIMM) report found there has been a 22% increase in the number of organizations creating software bills of materials (SBOMs) this year. Additionally, there has been a 10% increase in the number of organizations tracking open source software risks.

At the same time, there has been a 25% increase in the number of organizations that are fixing all defects found in software and a 15% increase in the number of organizations that can identify potential attackers and track attack patterns.

The report also sees significant gains in activities related to software development practices (44%), penetration testing (35%) and compliance and policy controls (21%). Usage of application behavior monitoring and diagnostics grew 64% and monitoring automated asset creation grew 45%, respectively.

The finding and publishing of secure design patterns, the required use of approved security features and frameworks and the use of application containers to support security goals all grew about 25%, according to the report.

However, the report also noted that usage of possible attack lists dropped by 31%, while expert-driven tasks such as building and applying adversarial security tests declined 25% and use of centralized defect reporting dropped 18%.

The most widely used processes are implementing security checkpoints and associated governance (91%), creating or interfacing with incident response (90%), identifying privacy obligations (88%), using external penetration testers to find problems (88%), ensuring host and network security basics are in place (87%) and automated code review tools (86%).

Jamie Boote, associate principal security consultant for the Synopsys Software Integrity Group, said the report suggests more responsibility for cybersecurity is shifting everywhere as organizations rely more on automation to apply security controls. Application development and IT operations are, as a result, able to address vulnerabilities more proactively either before an application is deployed or as soon as a vulnerability is discovered, he noted.

The challenge organizations will encounter when it comes to automating security processes is there is a tendency to set and forget. Once a process becomes automated, not enough organizations will reevaluate that process as the cybersecurity threat landscape continues to evolve, noted Boote.

Of course, the rate at which security processes are being automated varies widely from one organization to the next, but the more automated they become, the less dependent organizations become on application developers who typically don’t have a lot cybersecurity expertise. All too often, application developers are rushing to meet software delivery deadlines at the expense of security best practices. Unfortunately, it’s usually only a matter of time before an issue that was avoided is later discovered in a production environment and is considerably more problematic to update, given all the dependencies between software and infrastructure that exist.

One way or another, however, a pending wave of regulations will soon force organizations to pay more attention to securing software supply chains. The only thing left to determine in the absence of automation is how painful the reengineering of DevOps workflows to embrace DevSecOps best practices is going to be.

December 5, 2023
How Encryption Innovation Will Power Cloud Privacy for Developers in 2024

For developers, the surge in cloud computing adoption has brought both new opportunities and challenges. On the one hand, developers are turning to cloud services for data storage, processing and accessibility due to their flexibility, convenience and cost-effectiveness. And because the cloud takes care of these infrastructure and operational concerns, it’s allowing developers to focus on coding, innovation and delivering value to end-users. It also allows companies to scale more easily when their market grows or when new hardware becomes available.

However, this paradigm shift has led to the accumulation of vast volumes of sensitive data on remote cloud servers—including personal, health, financial and proprietary business information. As the volume of sensitive data on the cloud continues to grow, it has naturally raised mounting security concerns, from data breaches and cyberattacks, to unauthorised access and the complexities in complying with specific industry regulations, such as GDPR or CCPA.

For some, having to rely on the cloud provider to maintain robust security practices and data protection has also led to hesitancy in sharing data, both within and between organizations. This not only limits the potential for data-driven collaboration, research, and innovation—essentially halting progress in fields like health care, science, and social sciences—but businesses of all types and sizes could miss opportunities for cost savings, scalability, and efficiency if they’re not willing to adopt innovative technologies. There are also cases when companies are forbidden to do something by law because of privacy, again causing roadblocks.

All of this has meant that up until now, maintaining data privacy while making the most of cloud computing has been somewhat of a balancing act for developers and companies. Companies want to fulfill their clients’ needs, while developers have to find technical solutions that provide the level of privacy required.

Traditional Encryption methods Vs. Fully Homomorphic Encryption (FHE)

Currently, there are several technologies and practices employed to protect data in the cloud, one of the most commonly used being traditional data encryption, which provides protection only during data transmission and storage.

However, when data is processed, it must be decrypted—at which point it can expose data to eavesdropping, rendering it susceptible to potential threats. The aim of FHE is to ensure that the computations can be carried out on cloud-based machines while the data itself remains encrypted. With FHE, the data is really encrypted end-to-end: not only is it encrypted during transport and storage, but also it is encrypted during computations. It is only when the data or results are sent back to the client side that they are decrypted.

This means that in the event of a data leak, the exposed information would be rendered meaningless without the decryption key, which stays securely in the hands of the owner. In other words, neither the cloud provider nor any potential spyware on the cloud machine would have the capability to decrypt the encrypted data.

This approach, which ensures sensitive data remains encrypted throughout its entire life cycle on the cloud, even during processing and analysis, significantly enhances data security and privacy.

Current Limitations and FHE’s Future Developments

While developers using traditional cloud services previously had to decide whether to use the cloud with some privacy concerns or forgo its benefits altogether, with FHE we are starting to see a possible shift in attention from users’ reliance on the cloud provider to a more user-controlled approach.

As FHE becomes more widespread, users gain the ability to make their computations over any cloud provider, even those they may not fully trust. This means the upfront costs of building new cloud platforms can be lowered by providing only FHE computation.

While the encryption of data ensures that computations are secure and no unauthorized access or breaches can occur, this new tech is not without its limitations. For the enhanced security FHE offers, there may come a trade-off of longer execution times. Presently, we are mainly reliant on CPUs for computations. However it’s worth noting that as the technology advances and hardware accelerators become available, the execution time is expected to improve in the future. In fact, we anticipate that by 2026, FHE implementations will see a considerable increase in speed, potentially by factors of 100x or 1,000x, expanding the applicability of FHE to a wider range of use cases.

Other benefits currently being worked on include usability. FHE had a reputation of being very complex and so used to be reserved for those with cryptography PhDs. By developing open source tools and extending the community’s knowledge around FHE, the aim is to democratize FHE so that anyone can use it, companies can experiment free of charge and check if it fulfills their needs.

Looking to the future, privacy will likely remain high on the agenda for almost everyone. Thankfully, with new encryption technologies rapidly developing in terms of speed and usability, developers look set to achieve this, ensuring their cloud-based applications and services are as secure as possible.

December 1, 2023
Is SASE the DevSecOps of Infrastructure Management?

DevOps gained traction when IT and Ops (operations) teams recognized that traditional silos and handoffs were leading to inefficiencies and delays in software delivery. While DevOps enabled seamless collaboration and delivered on its promise of speed and efficiency, security remained an afterthought. To overcome the security loophole, DevSecOps emerged, proposing a shift-left approach to security. It emphasizes conducting tasks like security scanning, vulnerability assessment, and compliance checks all throughout the CI/CD pipeline.

With DevSecOps, speed no longer comes at the cost of security.

The DevSecOps approach has helped organizations strike the right balance between security and agility in software development. As the infrastructure landscape continues to evolve with the rise of cloud and edge computing, resource-intensive AI and ML initiatives, and distributed workforces, organizations must establish a similar balance between security and ubiquitous connectivity. This is where secure access service edge (SASE) comes in.

SASE’s Philosophy is Similar to DevSecOps

As legacy networks — characterized by rigid hardware-based infrastructure — struggled to keep pace with the demands of modern business, SD-WAN emerged as a solution, providing flexibility, centralized management and dynamic traffic routing. However, when distributed computing and remote work virtually dissolved the corporate perimeter, perimeter-focused security tools were no longer sufficient either. Today, enterprises must extend their security capabilities to almost unlimited network access points.

SASE addresses this challenge by merging networking and security into a single cloud-native framework. It integrates the entire security stack across all edge locations, ensuring secure connectivity between users, applications and resources no matter where they are. Just as DevSecOps shifts security to the left, making it an inherent part of the entire SDLC (software development lifecycle), SASE shifts security to the network edge, making it an inherent part of network connectivity.

The strategic resemblance between the philosophy behind SASE and DevSecOps is uncanny.

1. Breaking Silos

DevSecOps breaks down the silos between DevOps and security teams, promoting collaboration and shared responsibility. In a similar vein, SASE unifies all network and security functions into a single architecture, effectively dismantling the conventional boundaries between the networking and security teams. It allows both teams to jointly manage, monitor, and secure the infrastructure and network traffic through a unified management dashboard. SASE also effectively breaks the data silos that leave security teams with no insights regarding the networking conditions. SASE’s single pane of glass visibility enables networking and security data correlation, broadening each team’s perspective and eliminating tunnel vision for accurate and robust threat detection and an enhanced security posture.

2. Embracing the Cloud

DevSecOps aligns perfectly with cloud-native technologies like infrastructure as code (IaC) and containerization technologies like Docker, making it imperative for cloud-first and cloud-ready organizations. On the other hand, SASE is inherently cloud-native. It delivers network and security services from the cloud, providing organizations with the agility and scalability needed to meet the dynamic demands of a distributed environment.

Traditional back-haul-based connectivity and perimeter-based security solutions introduce latency and coverage gaps. SASE performs network and security functions at the edge, closest to wherever resources and users are. This eliminates the need for disparate on-premises point solutions and extends corporate security perimeter to match the cloud’s global reach.

3. Agility Through Automation

DevSecOps emphasizes automation of security tasks, such as security checks, scans and compliance assessments, within its continuous integration and continuous delivery (CI/CD) pipelines. SASE also leverages automation for networking and security tasks, such as dynamic policy enforcement, AI-driven threat detection and response, and network optimization through dynamic routing and self-healing properties. Automation reduces the need for manual intervention, bolsters security, simplifies operational tasks and enables organizations to respond to evolving demands and circumstances faster, crucial for agile environments.

SASE as an Enabler for DevSecOps

Just as DevSecOps enhances security within the context of application development, SASE enhances security and efficiency within the realm of networking and infrastructure management. Both approaches share the common goals of integrating security, promoting automation and ensuring scalability. They may apply these principles to different aspects of IT and cybersecurity, but DevSecOps and SASE can work together seamlessly to support modern IT environments.

Many organizations adopting DevSecOps realize that they lack the necessary infrastructure to support this approach effectively. DevSecOps demands seamless global collaboration and the integration of security controls across the entire IT environment. This is something SASE can help with. It can simplify infrastructure management and enhance security for DevSecOps in several ways. It offers ubiquitous connectivity for seamless collaboration, provides built-in security measures for faster incident response and ensures reliable infrastructure. As such, these are all crucial aspects for achieving the ultimate DevSecOps goal of delivering secure and high-performance applications at speed. With SASE, organizations can set their DevSecOps up for success.

November 30, 2023
CISA, NSA Issue Supply Chain Security Guidance Report

The National Security Agency (NSA), Office of the Director of National Intelligence (ODNI) and Cybersecurity and Infrastructure Security Agency (CISA) have issued guidance to assist software developers and suppliers to shore up software integrity and security across various stages of the software lifecycle.

The report, Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption, was developed by the Enduring Security Framework (ESF) Software Supply Chain Working Group.

The report offered recommended practices as a framework for assessing and improving security practices concerning software development, release, updates, vulnerability notifications and mitigation.

The guidance also addressed the escalating cybersecurity threats targeting software supply chains, which have exposed vulnerabilities susceptible to exploitation by state adversaries.

It highlighted potential risks such as design flaws, integration of vulnerable third-party components, infiltration of supplier networks with malicious code and malware injections in deployed software.

To combat these threats, the report underscored industry best practices, emphasizing open source software management and software bills of materials (SBOM).

Specific areas covered include SBOM consumption, life cycle, risk assessment and operational implementation, ultimately promoting enhanced transparency and risk management throughout software life cycles for organizations.

Alex Kreilein, vice president of product security at Qualys, said while the concept of an SBOM is not new, organizations now have concrete and foundationally important guidance on how to make operational use of SBOMs while developing, managing or consuming them.

“The guidance supplied by the Enduring Security Framework reduces the complexity of SBOM management, making it accessible to everyone for the first time,” he noted. “SBOMs are part of a healthy software ecosystem, but are by no means the only factor.”

He explained that while the SBOM is an effective output, it cannot be trustworthy if the system that created it cannot validate the provenance of the product.

“It’s critical for organizations to understand the whole supply chain from code through pipeline to production,” Kreilein said.

He added that this is why The Linux Foundation and Google started the Supply-chain Levels for Software Artifacts, or SLSA framework, as a practical set of methods to action NIST recommendations in the Secure Software Development Framework (SSDF).

John Gallagher, vice president of Viakoo Labs at Viakoo, called the report a “major step forward” in providing an overall framework and transparency for how SBOMs are constructed, maintained and used.

“One of the key ways this helps relieve concerns over software supply chain security is by providing clear guidance on the risk scoring mechanisms,” he said.

This augments other software supply chain efforts (though it doesn’t replace them) in areas like the use of SBOMs in SaaS environments or version control mechanisms for SBOMs.

He noted two significant points on implementation that come out of this framework; first is that it gives guidance to departments like procurement as to what they should be requiring from their vendors, and second it gives a framework for solution providers to base their consumption and generation of SBOM and Vulnerability-Exploitability eXchange (VEX) data on.

“While this document does not address the methods of remediation, it does help to more quickly identify software supply chain vulnerabilities so that they can be addressed early on and ideally before the widespread use of that vulnerable code,” Gallagher said.

He noted that the more vulnerabilities that are caught early or before they are broadly used the later stage of remediation is either much easier or not needed.

Anthony Tam, manager of security engineering at Tigera, said when vulnerabilities have been identified, it is important to prioritize them based on severity and potential impact.

“This allows organizations to allocate their resources more effectively and focus on the most critical vulnerabilities first,” he explained.

Prioritization can be done by using a risk-based approach, considering factors such as the likelihood and potential impact of a vulnerability being exploited.

“By prioritizing vulnerabilities, organizations can ensure that they are addressing the most critical security risks first and reducing the overall risk to their software system,” Tam noted.

November 21, 2023
Where to Start With Secure Design – Tips for Developers

Designing secure software is an increasingly hot topic, and for good reason. In recent weeks, we’ve seen a global effort from governments and cybersecurity agencies to encourage security by design through new guidance and changes to procurement rules. During the G7 in May, the QUAD nations (Australia, India, Japan and the United States) released a set of Joint Principles for Secure Software. In the U.S., there are even plans for legislation to make software makers liable for the security of their products. The need for software to be made secure at the design phase has been spotlighted further by recent cybersecurity incidents such as the hack by ransomware group CLOP that exploited flaws in MOVEit software.

But secure design is not a part of every developer’s skill set, and it’s not on the syllabus of every coding course. If you’re brilliant at writing code and keen to know more about how you make that code secure, where do you start?

Here are five tips from former DevSecOps and threat modeling engineer Fraser Scott, now IriusRisk’s VP of product:

1. Get to Know the Threats

To be able to design secure software effectively, you need to understand the threats. A great starting point is the OWASP Top 10. OWASP aims to identify the most critical security risks to web applications. Top of that list is broken access control, and insecure design itself sits at number four. Understanding the biggest risks is the first step towards mitigating them in software development.

2. Try Threat Modeling

The foundation of secure design is threat modeling, which is the process of identifying and mitigating plausible security threats. In its simplest form, this is about looking at your software design and asking Adam Shostack’s four questions:

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?

The OWASP Top 10 gives you a sense of what the risks might be, and threat modeling is the process of identifying them in your design. See if any of those top ten risks might impact your design, consider what could go wrong and work out what you can do to mitigate it. Before you start writing any code, consider whether you’ve done a good enough job to make the software secure. The sooner you find design issues, the cheaper and easier they are to fix.

3. Connect With a Community

There are plenty of communities of people out there grappling with the same challenges that you are. Experts in security and threat modeling and developers are coming together to discuss and try to solve some of the key challenges in secure design. One such community is Threat Modeling Connect, where people use the forum to share ideas and discuss issues. Experts also host webinars and write blogs. The community also held its first-ever conference in October. There is also a community dedicated to threat modeling on Reddit, and the OWASP Slack has a #threat-modeling channel.

4. Experiment With Automation

Companies who are developing software on a large scale use tools to automate the threat modeling process. IriusRisk makes a community edition of its automation tool available for free, for life, to people who want to give threat modeling a try. As someone who is starting out in secure design, using a tool like this, which generates many of the relevant threats and countermeasures for you, is a great way to experiment with your first threat models. And we’re not the only ones; you can also use the OWASP Threat Dragon and Microsoft’s Threat Modeling for free.

5. Build a Library of Secure Code

One shortcut to secure design is using existing secure design patterns and road-tested components. As you develop software, keep a library of secure code that has been threat-modeled and scanned using application security testing tools that you can return to in the future. The Threat Model Cookbook on Git Hub has some sample threat models you can use as a starting point.

November 17, 2023
Elastic Previews Unified Query Language for Search Platform

Elastic this week previewed a standard query language that can be used across its portfolio to streamline investigations into IT and cybersecurity events.

Gagan Singh, vice president of product marking for Elastic, said Elasticsearch Query Language (ES|QL) makes it simpler, via a single query, to aggregate data from multiple sources using a piped query syntax that makes it simpler to iteratively interrogate data.

Scheduled to become generally available in 2024, ES|QL replaces the multiple domain-specific languages the company has been providing for each version of its search engine. Instead of having to move data into a central repository, Elastic Seach makes it possible to query data wherever it resides in an organization, noted Singh.

That approach enables, for example, a site reliability engineer (SRE) to discover the root cause of an issue through a series of queries that can be launched from a familiar search interface, he said. It will also foster increased collaboration across IT teams that need to visualize query results, added Singh.

In general, IT teams are struggling with an exponential increase in the amount of data they need to analyze to discover the root chaise of an issue, noted Singh. The Elastic search engine provides a means to analyze that data at the level of scale that is now required, he added.

The preview of ES|QL comes on the heels of a technical preview of a generative artificial intelligence (AI) tool for observability the company has made available. The Elastic AI Assistant for Observability makes use of large language models (LLMs) and the Elasticsearch Relevance Engine (ESRE) to explain application errors, log messages, alerts and recommendations for improving code in plain language. DevOps teams can visualize and interactively chat with telemetry data and then invoke runbooks to remediate issues.

Elastic has also generally made available a Universal Profiling tool to enable DevOps teams to identify bottlenecks that adversely impact code performance.

There is little doubt that fundamental changes to how DevOps and cybersecurity teams interact with telemetry data are on the way. The challenge now will be determining when to rely on a generative AI tool versus diving deeper into that data by launching a series of queries. At the very least, AI should provide DevOps and cybersecurity professionals with a better sense of where to start an investigation.

Ultimately, the goal should be to reduce the level of DevOps and cybersecurity effort that is currently required to succeed. In theory, as it becomes simpler to investigate issues, the number of organizations capable of embracing DevOps best practices should increase as well. That’s crucial because IT environments are only becoming more complex with each passing day. The number of dependencies that exist between services has become too numerous for IT teams to track manually. More challenging still, those services are dynamically being updated, so what was known today about them might no longer be relevant tomorrow.

Hopefully, the amount of time and toil required to address issues will significantly decline in the months ahead as the next generation of tools becomes available. The challenge now is hanging on long enough for them to be battle-tested.

November 10, 2023
Survey Surfaces Software Supply Chain Security Challenges

A survey of 268 security leaders and 252 developers published this week found that while there is general agreement on the importance of software supply chain security, there is a significant disconnect on what is required to achieve that goal.

Conducted by the Harris Poll on behalf of Chainguard, a provider of curated container images for building secure software, the survey found 92% of developers acknowledged software supply chain security is at least very important, with 39% noting it as absolutely essential. Similarly, 96% said effective software security practices are important to meeting government or regulatory requirements, with 93% noting effective software security as a critical component of their threat and risk mitigation strategy.

Overall, most security leaders (70%) and CISOs viewed software supply chain security as a top priority. However, only slightly more than half of developers (52%) agreed. Nearly three-quarters of developers (72%) said they are very security-conscious, but only 50% of security leaders rated developers as very security-conscious.

Roughly two-thirds of security leaders (69%) and developers (64%) agreed that lack of communication and collaboration between developers and security teams is a problem. More than three-quarters of security leaders (77%) and more than two-thirds of developers (68%) agreed that the need to prioritize security causes tension between their teams. Nearly three-quarters of developers said the work/tools their security team requires them to use interferes with their productivity and innovation. Tools in place included software bills of materials (SBOMs) (40%), and nearly half are implementing software supply chain security frameworks such as Supply-chain Levels for Software Artifacts (SLSA) (47%) and the Secure Software Development Framework (47%) defined by the National Institute of Standards and Technology (NIST).

The report also found that 36% of security leaders and 34% of developers viewed an overwhelming number of scanner false-positive vulnerability alerts as being among the biggest software supply security obstacles an organization faces.

Most security leaders (74%) and developers (85%) believed that prioritization of software supply chain security would increase over the next five years.

However, many developers don’t believe enough security teams understand core software. Developers said security teams are generally familiar with open source software libraries and projects (61%), source code repositories and source code management systems (60%) and software build tools (59%), but only 43% said security teams are very familiar with container images.

On the plus side, many security leaders and developers understand that best practices and tooling in software security to drive certain business outcomes is essential, including customer retention (43% and 40%), meeting or satisfying procurement contract obligations (36% and 32%), fewer breaches or compromises (34% each), and developer/engineer productivity (32% and 34%).

Kim Lewandowski, chief product officer at Chainguard, said the survey makes it apparent that while progress toward securing software supply chains is being made, much work still needs to be done as silos between the developers and security leaders who are ultimately responsible for application security persist. While more organizations than ever have embraced DevSecOps best practices to achieve that goal, the cultural and technical challenges many organizations encounter are often underestimated, she noted.

The issue, as always, is that given the limited resources available, many organizations, despite their best efforts, are clearly still finding it difficult to stay current with updates to remediate vulnerabilities as they become available.

November 9, 2023
Transitioning Legacy Systems to DevOps: The XDR Support Paradigm

In today’s rapid and evolving technological landscape, DevOps emerges as a frontrunner in development methodologies, promising agility, efficiency and continuous delivery. While companies are keen to leverage its benefits, the transition from legacy systems can be fraught with challenges. Integrating extended detection and response (XDR) while making this transition can serve as a powerful tool to manage these challenges. In this article, we will delve deep into the potential pitfalls of this transition and explore the remedial measures with the aid of XDR solutions.

The Legacy System Quagmire

Legacy systems are often monolithic, siloed and heavily dependent on older technologies. According to a report by Forrester, a staggering 72% of corporate architectures still run on legacy systems. These systems, while operational, often lack the flexibility and scalability required for a DevOps-driven environment. They can become roadblocks, slowing down processes and becoming vulnerable points of failure.

The Inherent Challenges

Scalability Concerns: DevOps emphasizes scalability. However, legacy systems weren’t built with this level of dynamism in mind. Most legacy systems face scalability issues when introduced to DevOps practices.

Security Vulnerabilities: The older tech stacks are more vulnerable to modern-day threats. Without continuous updates, these systems become an attacker’s paradise. This is where XDR solutions come into play, offering real-time threat detection and response across the infrastructure.

Integration Hurdles: Legacy systems often struggle to integrate with modern tools used in DevOps, from container orchestration tools like Kubernetes to configuration management tools like Ansible.

XDR to the Rescue

Holistic Threat Detection: XDR’s primary strength lies in its comprehensive threat detection across networks, clouds, endpoints and applications. This compensates for the potential vulnerabilities of legacy systems, providing a safety net.

Real-time Responses: XDR doesn’t just detect threats; it actively responds to neutralize them. As per a study by IDC, integrating XDR can reduce incident response times by up to 50%, ensuring that any security breach on legacy components is swiftly managed.

Forensic Capabilities: Understanding the root cause of issues is paramount. XDR solutions come with forensic capabilities, allowing teams to understand the “how” and “why” behind incidents, an essential feature when dealing with older systems that may lack documentation.

Migrating With Minimal Friction

Training and Skill Development: One of the most underrated challenges is the lack of skills in managing and migrating legacy systems. Investing in training and reskilling can bridge this gap. A recent survey by DevOps Institute revealed that 72% of organizations that prioritized skill development found transitions, including to DevOps, smoother and more efficient.

Pilot Programs: Before a full-blown transition, it’s wise to run pilot programs. This involves migrating a smaller, non-critical segment of the legacy system and integrating XDR support. The lessons learned here can guide the broader migration.

Continuous Monitoring: Post-migration is not the time to be complacent. Using XDR’s monitoring capabilities, teams should continuously oversee the newly migrated segments for any anomalies or performance issues.

Infrastructure-as-Code (IaC) and Legacy Systems

Bridging the Gap with Automation: DevOps heavily leans on the principle of automation, and infrastructure-as-code (IaC) plays a pivotal role in achieving this. However, legacy systems often don’t align seamlessly with IaC principles. By using IaC platforms like Terraform or CloudFormation, organizations can create templates for legacy systems, making them more malleable for DevOps operations.

Ensuring Compliance: One challenge with legacy systems is maintaining compliance, especially when regulatory standards evolve. IaC, when coupled with XDR’s continuous monitoring, can ensure that these older systems remain compliant. According to a 2021 report by Puppet, companies that adopted IaC methodologies witnessed a 60% faster compliance update implementation time on their legacy systems.

Cultural Shifts and Organizational Dynamics

The Human Element: While the technical challenges of migration are tangible, the human element is often overlooked. Employees used to legacy systems might resist transitioning to DevOps practices, fearing obsolescence or due to comfort with older methods.

Change Management: Addressing this requires an organized change management strategy. Workshops, seminars and constant communication can assuage fears and foster a culture of continuous learning. A study by the Harvard Business Review highlighted that organizations that integrated change management strategies had a higher success rate in technical transitions, including shifts to DevOps models.

Collaborative Approach: It’s essential to foster a collaborative environment where both legacy system experts and DevOps enthusiasts work together. XDR’s collaborative tools can be instrumental here, providing a platform where teams can discuss XDR solutions, share insights and collaboratively respond to threats.

Conclusion

Transitioning from legacy systems to a DevOps model is not a mere technical challenge; it’s a transformative journey for the entire organization. The challenges, while significant, are not insurmountable, especially with tools like XDR providing support. By understanding the pitfalls and leveraging advanced solutions, businesses can ensure a smooth transition and harness the power of DevOps to its fullest.

November 7, 2023
Backslash ASPM Platform Prioritizes DevSecOps Efforts

Backslash this week made generally available a namesake application security posture management (ASPM) platform that identifies and prioritizes vulnerabilities based on how easy they are to exploit and reach.

Backslash CEO Shahar Man said the goal is to provide a comprehensive approach to providing a vulnerability exploitability exchange (VEX) platform integrated with tools for software composition analysis (SCA), static application security testing (SAST), secrets detection and creating software bills of materials (SBOMs).

That approach makes it possible to visually model threats within the context of the actual application architecture, noted Man. Armed with those insights, it then becomes possible to address cybersecurity issues by pinpointing the lines of code impacted and also identifying the developer who wrote that code.

While there is a pressing need to improve application security, current DevSecOps workflows are inefficient because there is simply too much noise, said Man. Development teams are inundated with alerts that lack any meaningful context, so after a while, they simply start to ignore them, he added.

In addition, cybersecurity teams will often create a spreadsheet with a long list of vulnerabilities to be addressed without knowing whether the code impacted is accessible via the internet or whether the code that might be affected is actually running in a production environment, said Man.

Other issues may involve transitive dependencies in open source software that developers might not even be able to address without the maintainers of those projects providing a patch.

Streamlining DevSecOps workflows has become crucial in an era where organizations are about to be held much more accountable for the security of the applications being deployed. Today, development teams are lucky if they can allocate 10% of their time to remediate vulnerabilities. Organizations need to be certain that time is spent addressing issues that could have the most impact on the business. Otherwise, a level of fatigue sets in the results in developers making the same cybersecurity mistakes time and again, noted Man.

The Backslash platform, on average, identifies one critical toxic flow for every 100 security alerts produced by other tools, he added. Once critical issues are identified, it becomes possible to more effectively apply the limited resources available to improve the overall state of application security in a meaningful way.

The debate, in the meantime, over how far left to shift responsibility for application security continues. In theory, developers are in the best position to remediate issues, but most of them have limited cybersecurity expertise. DevSecOps teams are generally going to be in a better position to identify which issues need to be addressed based on the severity of the risk they might represent. Otherwise, it’s probable IT teams will wind up wasting their time fixing issues while others that might lead to a major breach or blithely ignored.

Regardless of the approach to DevSecOps, the need for a common framework of understanding is crucial if the cultural divide between development teams and cybersecurity professionals that has existed for decades is ever going to be effectively bridged.

November 3, 2023