staging-devopsy.kinsta.cloud

Tag: devsecops

  • The Everything-As-Code Revolution and the OWASP Top 10

    The Everything-As-Code Revolution and the OWASP Top 10

    After years of stagnation, the Open Web Application Security Project (OWASP) Top 10 list finally saw some shakeup.

    Most notably, insecure design debuted on the list as the number four security risk to web applications.

    “If we genuinely want to ‘move left’ as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures,” OWASP says.

    That hits the nail on the head. It’s a great sign for the industry that organizations are adapting and continuing to shift left responsibly, and points toward the everything-as-code future we’ve been imagining.

    This addition by OWASP finally recognizes a key reason why organizations struggle to move the needle on addressing security issues. A lot of security today is reactive and organizations find issues long after they deploy applications, leaving security teams to act as firefighters at a time when there are too few security professionals in just about every industry.

    To effectively move forward, we need a shift in thinking.

    Studies have shown that if organizations addressed these same issues in design, they would eliminate the costs of firefighting and significantly improve developer productivity. It would also free security teams to focus on the strategic needs of security. 

    This change from OWASP recognizes that security needs to have a seat at the table when key software design decisions are made and it requires empowering security teams in the same way the DevOps teams have been empowered to own and manage the application’s security design and implementation. 

    A Unique Inflection Point: DevSecOps

    Security breaches continue to pile up, yet many organizations haven’t reexamined their reactive approach, which ignores the architectural problems causing the issues. We can’t continue to operate this way.

    We need a more dynamic and comprehensive approach to security in cloud-native applications. We need to acknowledge the failure of detecting misconfigurations too late in the development life cycle. It’s impossible to scale that way, and you end up creating too many rules in the process.

    We need more proactive engagement, which can be difficult in an application development world where velocity is king.

    Developers and DevOps teams should view security as trusted partners and engage them early in the development life cycle. They should understand that they have a shared responsibility for security. Security teams should embrace automation that fits into the developers’ workflow and makes their lives easier by democratizing security.

    The Everything-as-Code Future

    If we can continue to shift left responsibly, we’ll keep moving the industry forward in a way that will have ripple effects, including in the OWASP top 10.

    In a perfect world, we would see frameworks and application infrastructure address the input validation issues that make up a large part of the top 10 today. Those issues should be off the list and the top 10 should focus on the systemic issues—like insecure design—that lead to the current list.

    As we move toward an everything-as-code world where the boundaries between the application and the infrastructure blur, OWASP may focus more broadly on everything-as-code, which would include a new class of issues such as cloud code, infrastructure-as-code, pipeline-as-code and security-as-code. While there’s certainly more work to do, that would be a strong signal that we’re moving in the right direction. 

  • Lock Down Your Toolchain

    Lock Down Your Toolchain

    We have done amazing things with Agile and DevOps, increasing IT responsiveness to levels that most people would not have believed and our business counterparts only dreamed of even a decade ago. Think about it—we can check in a single source file and kick off a chain of events that involves half a dozen or a dozen software tools that collectively shepherd an entire application through the development process to deployment. Through all of that, only deployment might require human interaction, depending upon corporate policy. In many places, even deployment does not require a person. Just development.

    We didn’t get to this point by moving slowly, and sadly, we did not get to this point by acting in a security-first manner. Thanks to the security-toxic mentality that DevOps was born in, we have had to go back and try to bolt on security where it was ignored initially. But we’ve largely managed that process. We have tools that handle privileges, monitor connections, scan source, look for vulnerabilities in support software, even scan entire container definitions before the build.

    Know what most of you still don’t have? A truly secure toolchain. This is bad policy. A knowledgeable attacker is going to go after one of the aggregate locations. Places like container management servers that give them access to a lot of resources. Or the toolchain, which gives them access to every bit of software the organization develops. If an attacker wants to do code injection without detection, the toolchain in charge of builds and deploys is it.

    And yet, for ease of use and keeping up with iterations, many of you have credentials for the toolchain stored in easily accessible places so that whichever tool is running the show has access to credentials for each piece of the toolchain. I wish I could say “No one keeps that data in flat files anymore,” But alas, I cannot.

    One of the reasons it is not sufficiently secured is that build toolchains fall somewhere between Dev security and Ops security. That means our teams that came from a development background are not focused on security for the build chain, and our teams/team members that came from an ops background are not focused on the toolchain selected and often initially deployed by developers.

    Which brings me to my recommendation. Put security professionals on the toolchain to verify it is locked down at every step. There are a lot of places for the toolchain to be insecure, not just poorly stored credentials. And the toolchain touches all of IT’s crown jewels.  So make sure it isn’t wide open. If your organization doesn’t have dedicated security staff, bring in consultants to review the toolchain and make recommendations. There are some great security teams for hire out there that will be happy to lend a hand.

    And keep rocking it. Your teams are building and deploying at a rate never seen before—even if DevOps is “slow” at your org, it is still likely faster than its predecessors—for doing anything. So keep working miracles, and lock down your castle’s the inner keep.

  • Future of DevOps: Trends to Watch

    Future of DevOps: Trends to Watch

    Technology is transforming every aspect of industry, and digitalization and automation have flourished in the past few years. DevOps has established itself as an indispensable software development methodology for successful digital transformation.

    According to a recent market survey, the DevOps market will exceed $20 billion by 2026, growing at a CAGR of 24.7% from 2019 to 2026. DevOps has facilitated rapid and dependable software development, delivery, improved quality and higher customer satisfaction.

    DevOps, too, is continuously evolving to meet the changing demands of the corporate environment. Let’s look at the future of DevOps and the trends you should expect to see.

    Serverless Computing

    DevOps teams will see a rise in the adoption of serverless architecture, mainly because of the massive capital and operational costs of server infrastructure. Numerous DevOps groups are working with modular components offering an overview of the pipeline. Moving these modular components to serverless architecture will empower groups to mitigate a few pieces of errands identified with pipeline architecture and focus on deployment and development of the product.

    Serverless computing streamlines overall DevOps operations, including the complete software life cycle, from development to deployment, testing and maintenance in one place. Also, serverless computing reduces the developer’s workload by taking care of server maintenance, such as cloud monitoring and system updates. Other prime USPs include flexibility, reliability, speed and cost-efficiency.

    Microservices Architecture

    Microservices architecture has been gaining popularity as an alternative to traditional monolithic architecture in the IT industry, and this trend is expected to continue. Microservices architecture is a pattern of organizing computer systems into segments that can scale on demand. A microservices architecture pattern is the next evolution of service-oriented architecture (SOA) that structures an application as a collection of coupled services. If one piece of the application fails, microservices make it easy to identify and contain the issue without disrupting the whole application.

    DevOps and microservices architecture enable decentralized teams to innovate rapidly, maintain control over their tech stack and standards, track performance metrics, supervise the development and release cycles and reduce overall consumption time by achieving shorter software release intervals.

    Low-Code/No-Code Applications and Platforms

    To keep up with the demand for new applications and features, many organizations have turned to low-code/no-code development to deploy applications swiftly. Adopting a low-code approach with DevOps is a game-changer. It enables developers to experience higher agility and gives the organization a competitive advantage in the fast-paced, demanding software market.

    Low-code applications allow non-technical ‘citizen developers’ to contribute to software development with the help of visual interface integration. In addition to end users, developers and DevOps engineers are set to play a crucial role in this trend, using low-code platforms and tools that offer drag-and-drop elements and other extensions. These low-code application development tools support every aspect of software development, including app ideation, analysis, software design, code development, quality assurance, deployment and documentation.

    DevSecOps

    Many large enterprises are integrating and automating security into DevOps processes. The transformation from DevOps to DevSecOps is expected to gain even more momentum in the future. According to a forecast, the DevOps market size is expected to reach $5.9 billion by 2023 at a CAGR of 31.2% during the forecast period.

    More companies will embed security controls earlier in the software development cycle to ensure application security. Tools and frameworks will simply integrate with CI/CD pipelines and testing tools will see a rise in 2022. DevSecOps empowers developers to consistently track, monitor and remediate security defects during the various stages of development while improving the speed of delivery and quality.

    Kubernetes and GitOps

    Kubernetes is an open source container orchestration platform emerging as an infrastructure trend on the operations side. Kubernetes will expand further into the software development space in 2022 and beyond. It will ease the task of starting a local Kubernetes cluster on a developer’s machine. Kubernetes security is expected to take center stage as well, through infrastructure-as-code (IaC) scanning.

    GitOps is a Kubernetes-related infrastructure trend that allows developers and IT operators to use Git to manage clusters and deliver efficient, secure applications without misconfigurations. It automates releasing incremental updates, and consistent delivery will enable developers to build, test and deploy software rapidly.

    AI and ML

    Artificial intelligence and machine learning have already transformed the way businesses operate nowadays. In 2022, it is anticipated that AI/ML will further streamline and accelerate every phase of the SDLC. It enables DevOps teams to enhance their performance through intelligent automation, improving feedback and managing alerts.

    Advanced analytical methods like predictive analytics are becoming increasingly important as the market evolves. AI can enable proactive investigation of the DevOps pipeline to identify problems and offer possible solutions. AI and ML integration also enable deep learning, data mining, statistics and modeling, becoming an integral part of your business’ workflow.

    Conclusion

    DevOps continues to evolve and pivot to drive significant IT transformations that directly bolster business goals and objectives. It will assist in enhancing the company’s ability to design, produce, launch and maintain high-quality software solutions. The above trends will help organizations move rapidly beyond automation, focusing on continuously improving outcomes. These trends are catalysts for creating a regular and dependable release pipeline and building better communication between development, IT and business teams.

  • How DevOps Teams Can Defend Against API Attacks

    How DevOps Teams Can Defend Against API Attacks

    Remember when ransomware was the main security threat that DevOps teams needed to worry about?

    Those days are over. Ransomware attacks are certainly still happening, but API security breaches—which increased by a whopping 600% in 2021—are now poised to become the top attack vector for threat actors, according to Gartner.

    That’s the bad news. The good news is that, in many respects, the security practices that DevOps teams already have in place to defend against ransomware can be repurposed to deliver API security, too—with a few tweaks.

    Keep reading for a look at the state of API security today, along with tips on expanding upon DevOps’ existing ransomware defense techniques to protect your APIs.

    The Preponderance of APIs

    Although it may seem surprising that APIs have suddenly become an attacker’s best friend, it’s actually not when you step back and think about how deeply dependent we’ve become on APIs over the past half-decade.

    APIs have been around for a long time. But until relatively recently, APIs were used mostly for specific types of applications, B2B or infrastructure integrations. It wasn’t until the pivot toward microservices and distributed architectures that internal (or east-west) APIs became the glue that holds application environments together and carries information (which is sometimes sensitive) between the components and micro-components of an application.

    As for external APIs, publishing public APIs has become a basic expectation for virtually any business with a software product—to the extent that there are now something like 22,000 public APIs out there as well as several orders of magnitude more internal APIs.

    The result is a world where APIs create potential attack vectors against virtually every application or service. It only makes sense, then, that the bad guys are increasingly focusing on exploiting APIs as a means of obtaining access to things you don’t want them to have.

    From Ransomware Protection to API Protection

    You might think that securing APIs requires fundamentally new security tools and practices. In reality, though, there are extensive parallels between mitigating ransomware risks and mitigating API security risks. And DevOps teams are a major line of defense against these.

    Here’s how to extend an anti-ransomware strategy to an anti-API-exploit strategy.

    Prevent Lateral Movement

    Like ransomware, which propagates from endpoint to endpoint laterally by exploiting flaws and vulnerabilities, API exploits also typically spread laterally across an environment.

    This means that even if you can’t prevent all API (or ransomware) attacks from breaching your perimeter, you can take steps to make it hard for breaches to expand. By detecting malicious activity inside your environment early on, you can stop lateral propagation of the threat before it leads to a largescale compromise.

    Focus on Data Security

    Ransomware attacks and API attacks are both focused on compromising the same crown jewel: Your data. Ransomware attackers want to hold that data for ransom. API attackers—such as those who stole sensitive information from compromised Peloton accounts, or others who breached LinkedIn’s API to scrape data about 700 million users—typically want to exfiltrate it, possibly to resell it or maybe just to harm your business’s reputation.

    Mitigating both ransomware risks and API security risks, therefore, boils down to securing your data. By enforcing strong access controls and segmentation over what both internal and public APIs can do, you mitigate the risk of data exfiltration due to API security breaches.

    Use Behavioral Security Models

    Investing all of your signature-based security controls in attack prevention doesn’t work well for either ransomware or API attacks, especially when they are zero-day or unknown attacks. While you certainly should do what you can to harden your environment, it’s impossible to guarantee that a breach won’t slip past your defenses.

    That’s why deploying behavior-based security models is key to protecting against both ransomware and API attacks. Behavioral security models detect anomalous activity inside an environment, such as unusual types of requests or strange request patterns. By modeling and baselining behaviors and detecting anomalies based on your model, you can prevent attacks from spreading once they are underway.

    Don’t Rely on Perimeter-Based Defenses

    Along similar lines, trying to protect the perimeter of your environment is not a surefire defense against either ransomware or API attacks. Instead, you need to distribute protections across all of your endpoints, applications, services and so on.

    Again, nothing will guarantee that attackers won’t get in. The success of your defense hinges, in large part, on your ability to make it hard for them to escalate their attack from a small-scale breach into one that impacts a wide array of resources.

    Look Beyond the Surface

    Ransomware and API attacks are similar in that both often involve attack methodologies designed to elude common security monitoring tools.

    For example, attackers might try to leverage ports 80 or 443 (the default HTTP/HTTPS ports), which will almost always be open on firewalls. It’s therefore imperative to avoid relying just on standard ports or on encryption to protect API traffic. Instead, you must look deep into the payload, then parse and understand the protocols. It is also important to monitor and collect data from multiple sources, then correlate and analyze them to a get a deeper understanding of what is actually going on within the environment.

    Conclusion

    To be sure, ransomware attacks and API security attacks are fundamentally different in some respects. They involve the exploitation of different protocols and the goals of attackers are usually a bit different.

    But in terms of how attackers operate, what they want to steal (your data) and the limitations of perimeter-based defenses, ransomware attacks and API attacks are actually pretty similar.

    That’s why developers and DevOps teams don’t need to rethink their entire security strategy to cope with the surge in API attacks. Instead, do what you’re already doing to protect against ransomware and use those techniques to help secure your APIs, too.

  • What SASE Means for DevOps Teams

    What SASE Means for DevOps Teams

    You have probably heard the acronym secure access service edge (SASE), and it’s hard to ignore its impact on the technology industry. SASE is a cool new way to implement networking in hybrid environments, and the most important thing about it is that it bakes security into the network fabric. In plain English—when you plug in, you are secure by default. 

    SASE will have a special impact on two fields near and dear to the hearts of DevOps teams:

    1. Cloud security—SASE has the potential to transform how we practice security in the multi-cloud, and unify it with security in the central data center.
    2. DevSecOps adoption—SASE can make DevSecOps easier to adopt and might become essential infrastructure for globally distributed DevSecOps teams.

    Let’s understand the anatomy of the SASE beast, and understand how it will affect DevOps in the years to come.

    What Is SASE?

    SASE is a cloud service that extends networking and security capabilities to support hybrid organizations’ dynamic, secure access needs. 

    SASE combines WAN capabilities with network and security functions, such as firewall-as-a-service (FWaaS), zero-trust network access (ZTNA), secure web gateway (SWG) and more.

    A SASE platform bundles multiple security capabilities, including SD-WAN and services like SWG, CASB, ZTNA, FaaS and SaaS. This multi-region, multitenant architecture supports a distributed and remote workforce. SASE uses inspection engines located at points of presence (PoPs) near the endpoints rather than in the data center. SASE clients send traffic to the nearest PoP. 

    The core characteristics of a SASE architecture are:

    • Global SD-WAN—A private SD-WAN backbone helps reduce latency by avoiding the public internet. 
    • Distributed architecture—SASE inspects traffic and enforces policies at the edge using multiple inspection engines. 
    • Cloud infrastructure—SASE delivers services via the cloud, so tenants don’t have to maintain hardware and other infrastructure resources. This approach is scalable and cost-effective.
    • Identity-based access—Access controls use identity markers like the user’s location and device. 

    SASE Adoption Drivers: Why Do Organizations Want It?

    Cost Reduction

    Using physical and virtual appliances from multiple vendors is highly cumbersome and costly. SASE enables organizations to replace this disparate model with a single, cloud-native solution. Organizations can use SASE to deliver more technologies and services via one provider instead of several. As a result, it eliminates the cost of miscellaneous network appliances and optimizes cloud costs, by reducing the resources and bandwidth needed to operate a cloud environment. 

    Edge-to-Edge Security

    SD-WAN is an integral component of SASE, providing features such as an active-active failover and WAN optimization that improve performance and increase network resilience. SASE solutions are based on the concept of security automation, with a fully managed network security stack that typically includes SWGs, next-generation firewalls (NGFW), next-generation network architecture and intrusion prevention systems (IPS). This model helps protect all edges, achieving better network visibility.

    Data Protection

    SASE provides a holistic data protection experience that automates multiple DLP processes, including data discovery and data classification of storage locations, data usage and data in transit. It employs various security measures, such as user and device authentication, to enable control over access to data and resources at all times. Additionally, SASE DLP seamlessly rolls out protection policies across the entire network.

    Impact: How SASE Will Transform the Cloud Security Stack

    The emergence of services like PaaS, SaaS and IaaS has encouraged organizations to allow remote work. The cloud supports distributed workforces and streamlines business processes, but it also exposes companies to network-based threats. Many organizations store sensitive data with third parties accessed online.

    The cloud security stack can easily become siloed, with team members unsure of their responsibilities and overlooking critical processes. A siloed stack is more labor-intensive and harder to track because the security team uses multiple security systems. It can also create alert fatigue, making it hard to identify threats. 

    While employees mostly work in the cloud, security efforts often focus on the data center. SASE shifts the focus to the cloud while ensuring seamless integration between security services.

    With SASE, a single provider delivers the entire security stack, ensuring it functions as a unit. For instance, an SWG uses threat intelligence data to block suspicious traffic, sending unidentified files to a sandbox for testing. The security team can manage the entire stack from one intuitive interface. 

    Most activities occur at the edge—SASE secures the edge using an identity-driven approach. It is also cloud-native, ensuring a seamless experience. 

    Impact: How SASE Will Promote DevSecOps Adoption

    SASE provides the following advantages for adopting DevSecOps.

    Facilitating Collaboration 

    SASE helps reduce the challenges involved in cross-team collaboration. Essentially, SASE combines network security with WAN optimization. Modern DevOps teams are physically separate but must work together, requiring reliable and secure connections between team members. 

    The DevOps approach emphasizes time-to-market, so DevOps teams look for ways to accelerate the CI/CD cycle and push releases faster. An important part of the process is reducing the DevOps team’s reliance on the network and security teams. SASE solutions help optimize performance and enhance security, so the DevOps team doesn’t have to wait for the infrastructure team to configure resources. SASE gives DevOps teams the necessary control and operational cadence without compromising security or performance.

    Enhanced Networking

    SASE can improve the overall network performance by providing integrated failover and load balancing capabilities. DevOps teams must have reliable connectivity and cannot tolerate disruptions when deploying new software or fixing bugs. Fast, reliable application performance is key to the DevOps workflow. 

    The SASE architecture improves the networking, ensuring the organization’s edge devices, cloud resources, data center and remote users remain connected. The DevOps team doesn’t have to handle the infrastructure because it is self-healing, fully optimized, and secure. The solution automatically switches to another path if a line fails or a path becomes congested.

    Security By Default

    SASE protects DevOps projects with built-in security features. When implemented properly, it integrates many security technologies into the network stack. The DevOps team doesn’t have to worry about attackers intercepting sensitive information. Every security service shares the same, unified context to increase visibility and fill gaps that are often present in traditional security architectures. SASE mitigates the vulnerabilities exploited by attackers using NGFW, SWG, IPS, MDR and antivirus services in a single architecture.

    SASE can secure internal applications and their interactions, reducing the burden on the DevSecOps team. Applications running on a SASE-based SD-WAN benefit from the added protection of zero-trust network access (ZTNA) and software-defined perimeter (SDP). These technologies help ensure that all interactions between applications and endpoints are secure. 

    Proprietary apps are often too sensitive to expose to the public Internet. SASE secures these applications by obfuscating traffic, securing all entry points with NGFW, and restricting access with zero-trust network architecture. It constantly inspects all internal application traffic for cybersecurity threats. 

    Conclusion

    In this article, I explained the basics of SASE, which packages multiple networking and security solutions into one managed service. 

    SASE is giving organizations a new level of flexibility and agility with regard to their core infrastructure and is introducing the concept of security-by-design. Instead of fighting hard to “secure all the things,” we are moving nearer to a world where the “grid” our organization operates on is secure by default. This won’t make DevSecOps any less important. But it will allow us to build our applications and services within a secure, controlled hybrid environment.

  • Security Compass Makes Visualizing AppSec Threats Simpler

    Security Compass Makes Visualizing AppSec Threats Simpler

    Security Compass this week updated its threat modeling platform for developers to make it easier to surface application security issues.

    The latest version of SD Elements 2022 adds support for developer-centric threat modeling diagrams, reusable components, more advanced reporting capabilities and 114 more just-in-time training (JITT) modules. In addition, Security Compass has now integrated its platform with the Black Duck software composition analysis (SCA) tool.

    Drew Koelemay, director of product management for Security Compass, said the goal is to make it easier for application development and cybersecurity teams to collaborate using a platform that visualizes cybersecurity threats within a DevOps workflow.

    That approach to application security is critical because it becomes easier for developers to understand how changes to applications improve the overall cybersecurity posture of complex app environments where there are lots of dependencies, he said.

    Once that visualization is achieved it then becomes possible to create reports highlighting the most prevalent threats and weaknesses across that portfolio, Koelemay noted.

    In the wake of a series of high-profile application breaches, organizations of all sizes are looking to better secure their software supply chains by implementing DevSecOps best practices. The issue that immediately arises is the cultural divide between application development teams and cybersecurity professionals. The Security Compass platform surfaces developer-centric visualizations of security issues to help bridge the historic divide that exists between those teams, said Koelemay.

    For the most part, cybersecurity professionals view development teams’ lack of cybersecurity expertise to be the root cause of many of the issues they encounter. It’s not that a developer deliberately sets out to build and deploy vulnerable applications. By the time the application is reviewed—often just a few days before it’s supposed to be deployed—it’s often too late to do much about most of the vulnerabilities that are discovered. Cybersecurity professionals and application development teams need to meaningfully engage each other much earlier in the application development life cycle.

    The simple truth is developers are not likely to reach out first simply because they don’t know what cybersecurity issues to look for in an application environment. Most of the time they are rushing to meet an application delivery deadline, which makes them perceive cybersecurity as a hurdle to overcome rather than an automated process integrated within their workflow. Cybersecurity professionals, therefore, need to find a way to more constructively engage developers. The onus is on cybersecurity teams to insert themselves at the front end of the application development process rather than waiting at the backend for an inevitable issue to arise.

    One way or another, application security is going to improve. The only thing yet to be determined is how painful the process will be. Tools that enable DevOps teams to see for themselves what issues are being encountered should go a long way toward reducing both the level of pain being experienced and the amount of time required to resolve the cybersecurity issue at hand.

  • Scribe Security Unveils Pair of Tools to Secure Software Supply Chains

    Scribe Security Unveils Pair of Tools to Secure Software Supply Chains

    Scribe Security today unveiled a Scribe Integrity tool that scans software artifacts to make sure they comply with IT organizations’ security policies before they are integrated into an application.

    The Scribe Integrity tool authenticates open source and proprietary source code before it is uploaded into a build. It assumes that all artifacts are “guilty” until they can prove their innocence, said Rubi Arbel, CEO of Scribe Security. That approach makes it possible to ensure the integrity of the overall software supply chain is maintained in a way that doesn’t adversely impact the productivity of developers, he added.

    In addition, the company launched GitGat, an open source policy-as-code tool based on Open Policy Agent (OPA) agent software that enables DevOps teams to periodically run reports that surface insights into the security posture of code residing in GitHub repositories.

    Arbel said that, in time, GitGat’s reach will be extended to add support for additional continuous integration/continuous delivery (CI/CD) platforms.

    The first release of Scribe Integrity addresses Node.js code and the npm package manager with support for additional types of code planned.

    The Scribe Integrity tool also identifies all dependencies to enable DevOps teams to generate an accurate software bill of materials (SBOM) as each software artifact is included in the application, he noted. That’s critical because it enables developers, IT operations and cybersecurity teams to simultaneously see what artifacts, including containers, make up an application, noted Arbel. In the future, the company plans to make available a Scribe Hub that will make it easier to share insights into those software artifacts, he added.

    A series of high-profile security breaches clearly demonstrated cybercriminals’ skill at injecting malware into software artifacts and compromise any application that incorporates that artifact into an application. That malware can then be activated at some later date to potentially compromise any number of downstream applications.

    Those incidents resulted in a greater appreciation for DevSecOps best practices to maintain the integrity of software supply chains. The issue that DevOps teams are trying to address is how to build more secure applications without slowing down the rate at which those applications are built and deployed. As such, DevOps teams are adding tools to the application development process that make it easier for developers to scan code before it is included in an application and verify the integrity of any software component that becomes part of a DevOps workflow.

    It’s unknown how long it may be before the adoption of DevSecOps best practices has a meaningful impact on application security. However, waiting to focus on security until after an application has been deployed is way too late. Cybercriminals today can discover flaws and misconfigurations in applications in a matter of minutes. As more applications are deployed, developers can find themselves spending more of their time fixing vulnerabilities than they do writing new code. A new approach to building applications that are secure from the ground up is clearly required.

  • Rezilion Launches Vulnerability Prioritization Platform

    Rezilion Launches Vulnerability Prioritization Platform

    Rezilion today announced general availability of a platform that enables DevOps teams to better prioritize remediation efforts by identifying which vulnerabilities both run in memory and actually impact a class or function that can be executed.

    Liran Tancman, Rezilion CEO, said the biggest DevSecOps challenge organizations face today is that the bulk of vulnerabilities that developers are tasked with remediating don’t constitute a significant cybersecurity threat.

    Rezilion has created a searchable proprietary next-generation vulnerability database (NGVDB) that identifies which issues impact specific classes and functions. That capability enables DevOps teams to de-prioritize close to 95% of software vulnerabilities, said Tancman.

    In addition, the Rezilion platform will surface remediation suggestions that lower the amount of disruption and/or cost, he said. A fully-automated remediation capability, for example, will automatically upgrade and test vulnerable software components and packages within a continuous integration (CI) pipeline that were found to be exploitable. In the longer term, Rezilion is also working toward surfacing remediation suggestions that might be addressed using an alternative to patching, said Tancman.

    The Rezlion platform is also integrated with IT service management platforms such as ServiceNow and project management tools such as Jira to make it easier to address vulnerabilities as part of existing workflows, he added.

    Most developers today are simply overwhelmed by the number of vulnerabilities that cybersecurity teams routinely ask them to patch, noted Tancman. The goal should be to enable developers to focus their limited time and effort on remediating the vulnerabilities that truly matter to ensure application security, he said.

    In addition, developers need to have more confidence in the fact that the patch they are being asked to make won’t break their existing applications, added Tancman.

    Vulnerability prioritization is, of course, at the heart of the long-standing divide that exists between DevOps and cybersecurity professionals. Spreadsheets filled with long lists of vulnerabilities are regularly created, but there is usually no context provided in terms of how severe a threat any given vulnerability poses. As a result, developers would allocate a small portion of their time to applying patches that are prioritized based on intuition and level of complexity rather than severity.

    Naturally, developers are going to allocate most of their time to creating new applications and features. For any DevSecOps initiative to succeed, it’s critical to ensure optimal use of the time allocated to remediation. Cybersecurity teams will continue to compile lists of vulnerabilities, but that list can now be triaged in a way that causes the least amount of friction.

    In the wake of a series of high-profile security breaches, there is now more focus than ever on securing software supply chains. The challenge is to find a way to better secure applications both before and after they are deployed in a production environment. There will always be vulnerabilities that are discovered after an application has been deployed. However, just because a vulnerability exists, that doesn’t mean it’s exploitable. The trouble with application security today is that, all too often, remediation efforts turn out to be a waste of time.

  • This DevSecOps Thing Is Real After All

    This DevSecOps Thing Is Real After All

    Whether you made it to San Francisco, California last month for RSA Conference or not, you don’t want to miss Tuesday’s DevOps Connect: DevSecOps Virtual Summit.

    On Tuesday, July 12, 2022, we are presenting a virtual broadcast of the sessions from our recent DevOps Connect: DevSecOps event at RSA Conference in June 2022. All of the great sessions will be available as well as some bonus sessions that didn’t make it to RSAC.  

    For me, this event was extremely gratifying because it served as validation that I wasn’t crazy all those years ago. When I started staging-devopsy.kinsta.cloud in 2014, I did so because I thought it would be great for security—back then it felt as though I was a lone voice crying out in the wilderness! Now, here we are in 2022 and DevSecOps is real. It is accepted, it is sought-after and it is changing the way software is developed, deployed and managed.

    When I put on the first DevSecOps event at RSA Conference seven years ago, it was a bit controversial. The idea of bringing together the security community with the DevOps tribe was like what I imagine peace treaty negotiations between two warring parties would be. The security folks said no one else cared about security. The DevOps people, like many other IT pros, claimed the security folks were just people who said no to all their initiatives. The lack of trust ran deep. But we kept at it—and while the situation is far from perfect today, so much progress has been made.

    This year’s event featured our best speaker lineup yet. Jim Zemlin, executive director of The Linux Foundation, kicked off the event by talking about open source and security—software supply chain, SBOMs and security, oh my!  Continuing the open source and security trend, CNCF executive director Priyanka Sharma presented a great session discussing cloud-native and DevSecOps.

    And you won’t want to miss two of my favorite sessions. The first involves my friend John Willis asking, “What would Deming do?” in his session at 11:30 a.m. ET. Given the current state of world affairs and the software and security market, what would Edward Deming, the patron saint of DevOps, say and do? John is a bit of a Deming expert himself, so his insights are spot on, I think. And second, Carolyn Wong (who is a superstar) talks at 12:00 p.m. ET in her session about pentesting at scale, pentesting-as-a-service and DevSecOps.

    But wait—there’s more! Chenxi Wang has a powerful session, delivered off the cuff, about the current state of DevSecOps, software supply chain security, investing and more; that’s at 9:55 a.m. ET.

    We’ll also feature two amazing panels: One is made up of the authors of a recent book, Reinventing Cybersecurity. The other features folks from Intel, Mitre, NIST and the U.S. Senate talking about security compliance with an emphasis on software supply chain security and SBOMs (see a pattern here yet?).

    And that’s just the tip of the iceberg—there is even more from this year’s event that you don’t want to miss. So, head on over and register—it’s free. Many of the speakers will be online, live, during their presentations to answer questions, network and offer their guidance. There are also exhibits and sponsor booths and other fun stuff like a yoga class and a DJ spinning great tunes.

    This DevSecOps stuff is real and you will learn a lot from these sessions. We can’t wait to see you there!

    While you’re at it, check out our upcoming CloudNativeDay Virtual Summit August 10, 2022, which is shaping up to be a great event, as well!

  • More Than Half of DevOps Pros Have Backdoor Access to IT Infrastructure

    More Than Half of DevOps Pros Have Backdoor Access to IT Infrastructure

    A survey of 600 DevOps professionals conducted by strongDM, a platform for managing access to IT infrastructure, found nearly two-thirds (64%) had productivity impacted on a daily or weekly basis because of access issues.

    It’s not surprising that, as a result, DevOps teams created a number of workarounds to gain access, even though those methods don’t comply with cybersecurity best practices, according to the survey. More than half of respondents (55%) maintained backdoor access to systems, and 42% have embraced shadow IT to get access to tools and systems they needed for their roles, the survey found.

    Worse yet, the survey found that 53% of respondents admitted they are sharing credentials across teams.

    Well over half (57%) of respondents said it could take days or weeks for access requests to be approved, with 40% reporting it takes days to add tools to existing access solutions. Nearly three-quarters (73%) of respondents also noted it requires 15 minutes or more to gain access to infrastructure.

    More than half of respondents (52%) said they have missed deadlines due to issues with accessing infrastructure, with 53% of those respondents being held accountable for the missed deadline even if it was caused by their lack of access to infrastructure.

    Justin McCarthy, CTO for strongDM, said despite all the hype surrounding identity management and zero-trust IT, it’s clear many organizations are still struggling with the basics of access control. That issue has been further exacerbated by the need to enable more DevOps professionals to work from home since the start of the COVID-19 pandemic more than two years ago, he added.

    Many of those organizations are still relying on virtual private networks (VPNs) even though it’s been shown that stealing the credentials to access those VPNs is relatively trivial, McCarthy added.

    In place of those approaches to access IT infrastructure, strongDM is making a case for a dedicated infrastructure access platform that manages and audits access to databases, servers, clusters and web apps. It is based on local client software, a gateway intermediary and configuration tools that track roles and permissions.

    The benefits of that approach span everything from lower IT support costs to faster onboarding of new IT staff, noted McCarthy.

    Managing infrastructure access for DevOps teams is, of course, always going to be a challenge. DevOps teams are made up of engineers—among the most challenging types of end users to support. Many of them will use their own expertise to circumvent any process they deem to be inefficient. The trouble is, many of those end-runs would not pass muster with cybersecurity teams responsible for access management. The challenge each of those cybersecurity teams needs to come to terms with is the amount of time they want to spend time looking for these cybersecurity policy workarounds versus making it easier to securely access IT infrastructure.

    The sad truth is both DevOps and cybersecurity professionals are wasting a lot of time and effort trying to outwit each other when that time could be put to better use.