devopsy.kinsta.cloud

Tag: application security

  • Survey Surfaces Massive Number of Application Vulnerabilities

    Survey Surfaces Massive Number of Application Vulnerabilities

    A survey of 16,510 IT and IT security practitioners published today by Rezilion, a provider of a platform for automating the remediation of software vulnerabilities, found nearly half of respondents (47%) worked for organizations that have a backlog of vulnerable applications. More than half (66%) said their backlog consisted of more than 100,000 vulnerabilities and the average number of vulnerabilities that need to be remediated is 1.1 million.

    The survey, conducted by the Ponemon Institute, also found more than half of respondents ( 54%) said they can only patch less than 50% of the vulnerabilities.

    Factors that keep teams from remediating included an inability to prioritize what needs to be fixed (47%), a lack of effective tools (43%), a lack of resources (38%) and not enough information about risks that would exploit vulnerabilities (45%).

    More than a quarter (28%) also said remediation is too time-consuming. The survey found that 77% of respondents said it takes longer than 21 minutes to detect, prioritize and remediate just one vulnerability in production.

    In addition, 85% said they spend more than 16 minutes detecting one vulnerability in development. A full 82% also noted it takes longer than 21 minutes to remediate one vulnerability in development. A majority of respondents said it is either very difficult (36%) or difficult (25%) to remediate vulnerabilities in applications.

    On the plus side, more than half (56%) said they use automation for vulnerability remediation, with 43% reporting times to respond are significantly shorter as a result.

    Rezilion CEO Liran Tancman said the survey makes it clear there’s still plenty of room for improvement. The number of vulnerabilities that need to be addressed is staggering, he said. IT teams need to focus their immediate efforts on identifying the vulnerabilities that are the most critical, he noted.

    Remediating those vulnerabilities will soon become a higher priority as more regulations focused on securing software supply chains come into effect. In fact, the software bills of material (SBOMs) that these regulations require will expose much of the dirty laundry that currently exists in application environments, said Tancman.

    Ultimately, the goal needs to be enabling organizations to address vulnerability issues without slowing down the rate at which applications are being built and deployed, Tancman added. The degree to which that goal can be achieved will vary widely as more responsibility for security is shifted left toward application developers. However, the need to provide tools to developers that enable them to address vulnerability issues has never been more apparent, noted Tancman.

    It’s clear the level of application security vulnerability debt that organizations will need to address can no longer be ignored. The issue now is to determine how best to resolve these issues either by fixing existing applications or replacing them with new ones. Either way, it’s clear that there is a need to adopt DevSecOps best practices to better secure software.

    In the meantime, as application security becomes a boardroom-level issue, there be a lot more scrutiny applied all across the software supply chain.

  • Dynatrace Extends Reach of Application Security Module

    Dynatrace Extends Reach of Application Security Module

    Dynatrace has extended the Application Security Module it provides for its observability platform to protect against vulnerabilities in runtime environments, including the Java Virtual Machine (JVM), Node.js runtime and .NET CLR.

    In addition, Dynatrace has extended its support to applications built using the Go programming language.

    The Dynatrace Application Security Module leverages existing Dynatrace tracing and artificial intelligence (AI) technologies to detect threats in real-time and then apply appropriate policies to automatically secure applications. At the core of the Dynatrace approach to application security is its OneAgent software for application instrumentation, which collects data and feeds it back to an observability platform that includes an AI engine dubbed Davis.

    Amit Shah, director of product marketing for application security at Dynatrace, said by extending the Application Security Module to support runtimes in the most widely adopted programming languages Dynatrace is now providing real-time visibility and vulnerability analytics across the entire application stack, which includes custom code, open-source and third-party libraries, language runtimes, container runtimes, and container orchestrators.

    The Dynatrace platform not only identifies vulnerabilities across each of these layers automatically but also analyzes them to reduce false positives by only surfacing alerts concerning code that is actually running, noted Shah. Without those capabilities, it becomes impossible for development teams to prioritize their application remediation efforts in the absence of any context, he added.

    In general, achieving and maintaining application security will require more responsibility to shift both left and right, said Shah. While it’s critical to discover as many vulnerabilities as possible before applications are deployed it’s also crucial to make it simpler to discover vulnerabilities in runtimes after an application is deployed, he noted. The goal is to enable DevOps teams to employ the same observability platform they are using to manage and optimize applications to also ensure application security, Shah added.

    That Dynatrace approach provides the added benefit of also avoiding the need to convene a “war room” to discover where all the vulnerabilities in those application environments might reside once they are discovered, Shah noted.

    The primary application security challenge organizations face is the rate at which applications are now being deployed. Cybersecurity teams, because of a chronic shortage of talent and expertise, can’t keep pace. As a result, more responsibility for application security is being shifted left toward developers and DevOps teams as well as right toward IT and security operations teams. In effect, application security is finally becoming a team sport within IT organization as cybersecurity teams focus more of their efforts on securing runtime environments, noted Shah.

    It may be a while before that approach has a major impact in terms of reducing the number of vulnerabilities being regularly introduced into application environments. However, as more tools and platforms that specifically address application security are deployed, the overall state of application security will steadily improve.

    In the meantime, however, the volume of attacks aimed at the application layer of the IT stack will, unfortunately, continue to increase as cybercriminals focus more of their efforts on exploiting both now and zero-day application vulnerabilities that are increasing in volume with each passing day.

  • Turning Off DevSecOps Noise for Functional Fidelity

    Turning Off DevSecOps Noise for Functional Fidelity

    Analyzing the DevOps and DevSecOps software marketplace demonstrates the high demand for tools and platforms that reduce false positives. As businesses and organizations adopt a rigorous, disciplined software development life cycle and ascribe to strict compliance frameworks, they quickly realize that automated tools can generate a substantial amount of noise, in the form of false positives, that pollute their efforts to maintain a lean and focused operation.

    True Positive Vs. False Positive Vulnerabilities

    Static application security testing (SAST) is fundamentally about using pattern recognition to identify vulnerabilities in code. The more aggressive the scan rules, the more likely a snippet of code will be flagged as a vulnerability; in other words, a “true positive” finding. Automated scanning is fundamental to effective DevSecOps. But if the scanning is too aggressive, it may generate findings that aren’t actual problems; in other words, false positive findings 

    You want your scan to return true positive findings—actual vulnerabilities that can be fixed and remediated. A false positive is a finding that isn’t actually a vulnerability. The ideal tool catches all the true positive vulnerabilities and returns a minimal number of false positives.

    Many platforms give their users granular control over which rules run and are applied to their code. This first layer of control is similar to allowing your team to tune their scans to focus only on certain frequencies while ignoring others. Often, this is used to increase the speed with which a platform might complete a scan. It can also be used to tune out “noisy” rules. It’s perfectly legitimate to use controls like these, but it’s important to recognize that those completed scans aren’t comprehensive.

    Speeding Up Can Slow You Down

    Positive findings, whether they are true or false, take more time and resources to evaluate and remediate. Investing resources to remediate true positives is worthwhile. It would be ideal if they had been caught earlier in the process, but catching a vulnerability before it hits production is the entire reason you are doing DevSecOps in the first place! False positives may not require actual remediation, but reviewing them and then manually confirming their false nature is directly counterproductive to the reasons an organization adopted automated SAST in the first place.

    SAST Plus DAST Keeps You Ahead

    The gold standard for effective security testing is to pair SAST with dynamic application security testing (DAST), sometimes also called interactive application security testing (IAST). This process will correlate the positive findings from the SAST scans and test them using simulated data in an emulated runtime environment. 

    DAST/IAST actually tests each bit of code that looks problematic because of a particular pattern and then tests whether the code is actually vulnerable. DAST provides an automated, testable, repeatable and provable method to test those positive findings for trueness and falseness. If you are only doing SAST scanning, then the noise-to-signal ratio from your platform is governed strictly by the intelligence embedded into their pattern-matching code. Depending on the quality of the tool being used, your actual mileage may vary.

    DevSecOps Is the Right Path

    Businesses and organizations clearly understand the problem of potential vulnerabilities. Guarding against a security breach is critically important to protecting proprietary information and the privacy of their customers. DevSecOps is clearly the right path to take to reach that goal. However, it is critically important that the vehicle(s) these teams use to get there (in this case, SAST and DAST/IAST) have built-in functionality to focus their efforts on real problems and not waste it on phantom issues.

  • The Two Types of Code Vulnerabilities

    The Two Types of Code Vulnerabilities

    Spell checkers, grammar checkers and predictive keyboards all help reduce errors in written communication, but in a creative medium where writers need to innovate new expressions, nothing can eliminate all errors. The same is true in the code we write.

    Of course, your code is probably perfect but, on average, all code has bugs. Some of those bugs are benign. Some will cause unexpected early termination. A few will cause runaway resource consumption. And some bugs lead to security vulnerabilities that let users do things that are unexpected and sometimes undesirable.

    Those security bugs are behavioral vulnerabilities because they depend on how the code behaves when executed. Another type is an intelligence vulnerability, something that’s part of the correct behavior of the code, but which gives away details about how to exploit a system. These are the two main types of code vulnerabilities; both come with risks.

    Behavioral Vulnerabilities at Runtime

    Tl;dr: How the code works and how attackers can leverage what it does to their advantage.

    This covers a broad range of problems, but all of them are a result of the behavior of the code leading to undesirable outcomes in specific circumstances. Most of these are unintentional. An unescaped user input sent to a database can lead to a SQL injection vulnerability or an unsanitized string sent to a browser could create a cross-site scripting (XSS) vulnerability. Some behaviors are intended, but have unexpected consequences; the Log4j string substitution behavior that allowed it to output environment variables or read data from external resources was intentional, but the malicious usage we now call Log4Shell was not. In another recent example, a combination of behaviors could be exploited to gain root privileges on Linux desktop computers.

    Intelligence Vulnerabilities in the Content

    Tl;dr: What the content of the code tells an attacker about the system and how to access it. 

    In the 1950s, the phone company—there was pretty much just one at the time—began implementing completely automated dialing that didn’t require a human operator at the switching station to connect the call. The details were first published in a technical journal in November 1954 (see pages 1209 and 1309 here), and the information gleaned from that led to the creation of “blue boxes” that used insider knowledge to allow outsiders to control telephone equipment and make free long-distance calls.

    That’s hardly the first example of insider knowledge being leveraged for outside advantage, but its role at the heart of computer hacking and the origins of the PC (the ‘hack’ inspired Wozniak and Jobs) is so legendary that it demands recognition here.

    The phone system’s intelligence vulnerabilities were published in the company’s technical manuals—manuals that many thought were only for internal use, and nobody realized were available to untrusted readers. Today, though, intelligence vulnerabilities are in our code.

    Secrets abound in code, along with the details about which systems those secrets connect to. These secrets were once difficult to manage and putting them in code was the only practical choice. Now we have tools like Hashicorp Vault, as one example, and secure keystores in almost every cloud, but the legacy and security debt of all those secrets in legacy code are a goldmine for attackers like Lapsus$ and others who specifically target code.

    Security Is a Process, not a Product

    There’s a lot hidden under the surface in the two categories outlined here. Each of us can name many types of behavioral vulnerabilities—many more than the different types of intelligence vulnerabilities—but the two classes of vulnerabilities represent relatively equal risk. Recent events have demonstrated how an attacker with inside knowledge gleaned from code—and with passwords and keys taken from it—can move quickly despite firewalls and other access controls.

    Identifying secrets and other intelligence risks in code is relatively easy, but few teams do it because detection is the easy part. Integrating detection in developer workflows so they can take action in-context while working on and reviewing code is the most effective way to eliminate creating new security debt. And tools that give developers the information they need to understand the overall picture of intelligence risks in their code, the areas of highest risk—and that point them to actionable issues they can fix immediately to improve their code health—are necessary to help teams mitigate historical risks, ideally by rotating any secrets found.

    Tools exist that can automate that process and help teams to eliminate more than half the risk in their code—but the first step is recognizing where that half resides.

  • ShiftLeft Report Reveals State of Application Security

    ShiftLeft Report Reveals State of Application Security

    A report published today by automated application security testing platform ShiftLeft found only one in three applications has an attackable vulnerability. The report also found organizations that prioritized their remediation efforts based on the level of actual threat are fixing 76% of those vulnerabilities within two sprints lasting 12 days, on average.

    Based on millions of scans performed in the last year using the ShiftLeft platform to identify vulnerabilities, organizations have reduced the number of vulnerabilities they need to address by 97% on a year-over-year basis, the report found.

    In addition, the report noted that the average median scan time is only 90 seconds, which helped drive an overall 68% increase in daily scans year-over-year. Overall mean-time-to-remediate (MTTR) has dropped by 37%, the report also found.

    ShiftLeft CEO Manish Gupta said given the increased number of vulnerabilities, it’s more critical than ever for organizations to focus their remediation efforts on those that can be exploited within their IT environment. For example, the report found that only 4% of all Log4j instances discovered in the IT environments analyzed were vulnerable. Rather than spending weeks looking for every instance, Gupta said IT teams would be much better off focusing their efforts on the instances that might actually be exploited.

    The challenge is that not enough organizations have a way to score vulnerabilities based on the risk they represent to the business, Gupta added.

    While there is a lot more focus on adopting DevSecOps best practices in the wake of a series of high-profile breaches of software supply chains, the ShiftLeft report made it clear that presenting developers with a long list of potential vulnerabilities is counterproductive. The bulk of vulnerabilities that are being discovered are not actually attackable, noted Gupta.

    That doesn’t mean application security doesn’t need to improve, but it is clear that a lot of time and effort is being wasted, added Gupta.

    In theory, at least, as the cultural divide been application development teams and cybersecurity teams continues to narrow, the overall ability to prioritize remediation efforts should improve. The first step toward achieving that goal is making it easier to identify what percentage of the application attack surface is really vulnerable. Otherwise, developers presented with a long list of theoretical vulnerabilities will continue to prioritize developing new features and capabilities versus remediating vulnerabilities.

    One way or another, vulnerability remediation issues will soon come to a head. In the wake of an executive order from the Biden administration to improve overall application security within federal IT environments, many organizations will adopt similar policies and processes. Developers, naturally, will inevitably either push back or do an end-run around processes they deem too onerous. Rather than allowing a stalemate to occur, Gupta said savvy DevOps teams will invest more time in identifying the critical vulnerabilities that need to be addressed before cybercriminals exploit them.

    The issue, of course, is that cybercriminals are getting more adept at discovering and exploiting those very same vulnerabilities.

  • What the New OWASP Top 10 Changes Mean to Devs

    What the New OWASP Top 10 Changes Mean to Devs

    The open web application security project (OWASP) recently updated its top 10 list of the most critical security risks to web applications after four years. It represents the most radical shake-up since the list was introduced in 2003. The changes will undoubtedly have a big impact on how businesses address application security going forward and how developers and DevOps teams approach their jobs. This article will look at three of the most significant changes that have emerged in the new top 10 list.

    OWASP

    New Methodology for Current and Future Threats

    This time, OWASP took a more data-driven approach to their research to get better insight into current and future threats. Members provided more than 1.5 million data points on the security threats they see. OWASP categorized the data and assigned an impact score before deriving their overall ranking.

    OWASP also included survey data from security professionals about emerging threats. For example, the current incident rate of server-side request forgery (SSRF) vulnerabilities is low, but security professionals consider this attack very serious and expect it to increase significantly in the future. SSRF enables attackers to use vulnerable servers to request and receive data from protected internal sources, which is a very serious risk. So, SSRF became a new category (A10:2021) this year.

    With this new methodology, OWASP is now able to offer comprehensive insight into the most serious current and future threats.

    OWASP 10 Expands Security to the Left

    One key change in the new top 10 list is the inclusion of many categories (e.g, Insecure Design—A04:2021, Software and Data Integrity Failures—A08:2021) that recognize the industry has to start with better application design practices to improve security.

    Many application vulnerabilities creep into software because secure design principles are not followed from the outset. In the race for faster app development, corners are being cut. The CI/CD approach to application development is a major contributor to the use of plugins, libraries or software modules of dubious integrity. This problem is getting worse. Businesses must ensure that all their software components are from reputable sources and should use software supply chain tools to check for known vulnerabilities.

    Major Ranking Changes due to the Evolving Threat Landscape

    Injection attacks, which have been ranked as the number-one risk since 2003, are now ranked number three. While this is welcome news, we cannot claim victory just yet. Your valuable data is still very much at risk from vulnerable apps that allow bad actors to run unauthorized commands and access the sensitive corporate information your business depends on.

    Injection attacks have been replaced by broken access control (A01:2021). OWASP reported that in their data set 94% of applications were tested for these vulnerability types and 3.8% showed one or more weaknesses. A staggering amount!

    Due to the increased adoption of standardized authentication frameworks which are more readily available and easier to implement, identity and authentication failures (A07:2021) have plummeted in the ranking from number two to number seven as a risk.

    This shift demonstrates that as businesses have improved their determination of who can access applications, they have neglected to enforce controls over what an individual user, process or device can do in that application. It is crucial to consider authentication and authorization together for a better security posture.

    Lots of Work Ahead to Bring Left and Right Security Together

    The 2021 OWASP top 10 list is a big step forward. OWASP’s expansion of security to the left with the inclusion of new categories and significant changes to their rankings will require businesses to revaluate their application security posture. Addressing security earlier in the application development life cycle will likely prevent many of the more common attacks, but businesses must complement this with robust, proven and scalable security protections on the ‘right’ like web application firewalls. It is not just about shift left, it is about expand left. You need both left and right security for a better multilayered security posture.

  • Jit Emerges to Address Cybersecurity Policy-as-Code Orchestration

    Jit Emerges to Address Cybersecurity Policy-as-Code Orchestration

    Jit today emerged from stealth with a free namesake orchestration platform beta that automatically implements security plans as code.

    Aviram Shmueli, chief product officer for Jit, said the company will both make security plans it developed available as code within GitHub. In addition, Jit will make available a service through which customers can submit documents and spreadsheets that Jit will convert into a custom security plan that can be executed as code.

    Fresh from raising $38.5 million in seed funding, Jit is aiming to advance the adoption of DevSecOps best practices by enabling cybersecurity policies to be more easily implemented as code via its orchestration platform, said Shmueli. The Jit platform enables developers and DevOps teams to take advantage of a graphical tool to automatically implement security policies within a DevOps workflow with a single click, he noted.

    The goal is to eliminate the need for separate DevOps teams to create security policies that each would need to individually manage, added Shmueli.

    In theory, DevSecOps best practices require shifting left the responsibility for security toward application development teams. The challenge is that development teams generally don’t have the expertise required to craft effective cybersecurity policies. Jit is making a case for a platform that makes it simpler to automatically implement vetted cybersecurity policies.

    Exactly how far responsibility for application security will shift left remains to be seen. Developers generally prefer to spend as much time as possible creating business logic rather than implementing cybersecurity policies. As such, it’s frequently left to a DevOps team to find a way to consistently implement cybersecurity policies across multiple applications. Each DevOps team will need to decide how much they can rely on the policies defined by Jit versus opting to implement a set of policies defined by their internal cybersecurity teams. The issue that often arises is cybersecurity teams lack programming skills; the only means available to define cybersecurity policies is some type of document or spreadsheet that, one way or another, needs to be converted into code.

    Given the ongoing chronic shortage of cybersecurity expertise, it’s apparent that more efficient methods for sharing cybersecurity best practices are required at a time when application environments continue to both rapidly expand and increase in overall complexity.

    Regardless of the DevSecOps approach, the pressure to address application security is mounting in the wake of a series of high-profile cybersecurity breaches. Organizations of all sizes are now reviewing software supply chains that are increasingly being targeted by cybercriminals. Security policy-as-code tools make it possible to ensure that applications don’t, for example, communicate with an external system without express permission.

    One way or another, the level of application security currently being attained will improve in the months ahead as more mandates are enforced. The only real issue remaining is the amount of disruption to existing processes that will be required to achieve that goal.

  • When DevOps-as-a-Service (DaaS) Meets Security

    When DevOps-as-a-Service (DaaS) Meets Security

    One of the most recent IT methodologies to be offered as a service is DevOps, a cultural and practical approach that brings development and operations teams together under one umbrella of work. DevOps-as-a-Service (DaaS) ensures that everything related to the selection, management and maintenance of DevOps tools and infrastructure, including all policies and procedures, are addressed through a centralized team who are able to provide this service to development teams across the organization. 

    From a 30,000-foot view, DaaS represents DevOps capabilities made accessible to practitioners through portals and APIs. Because DevOps capabilities vary among organizations, there is no standardization of these services. For the business, DaaS enhances competition. Application users and developers find DaaS improves overall software development, while specialized DaaS teams say it improves the management of DevOps capabilities.

    What Are the Other Benefits of DaaS?

    DaaS offers many benefits, especially to development teams who no longer want to spend all their time configuring and deploying the necessary security tools to run DevOps pipelines. This means it’s no longer necessary to understand all the differences between DevOps tools and the underlying infrastructure, as the appropriate tools and technologies are automatically deployed for development teams. As a result, developers are able to focus their efforts on creating innovative software at the speed of business. 

    Further, Daas delivers clear business and operational benefits in the form of a more streamlined process for facilitating DevOps across the enterprise. Daas supports governance while also enabling centralized oversight and visibility into development workloads and productivity. As we know, this shift leads to increased accountability among teams and an overall optimization of business processes. Add on resource efficiency and cost savings through tool selection, and it’s easy to see why DaaS has found a home in the world of software development. 

    But despite the benefits, Daas also presents new security challenges that can’t be fully addressed by traditional management solutions. These approaches are often sluggish, expensive, and/or incredibly complex to manage.

    What About Security and DevSecOps?

    Because the principles of DevSecOps proactively address the risks and threats associated with DevOps processes, it has seen rapid adoption in recent years. By integrating AppSec tools and strategies within a DevOps pipeline, developers are able to find and fix security vulnerabilities earlier within the software life cycle—not after the fact. This ability is what allows developers to generate secure and high quality software from the beginning, while also preventing any deployment delays stemming from last-minute security checks in production. With DevSecOps processes in place, AppSec testing becomes seamless and transparent for developers, who need a frictionless experience to facilitate steady and reliable software development and deployment. 

    DevSecOps is a  natural fit for the as-a-service delivery model. Similar to DevOps, AppSec involves various tools, policies and processes that demand a certain degree of professional expertise—not to mention the time and resources it takes to to select, maintain, and deploy them to drive DevSecOps practices. Security and development teams looking to  implement and manage DevSecOps can reap major benefits from a centrally defined and managed process, to be administered by a specialist team and delivered “as a service” to those in charge of DaaS.

    Standardizing AppSec through a DevSecOps-as-a-Service offering would guarantee security is applied evenly across all DevOps activity, thereby allowing businesses to produce secure and high-quality software consistently while also supporting AppSec compliance demands. This shift also establishes a foundation where a holistic and homogenous view of AppSec can be found, one that is critical to the assessment and management of application and business risk. 

    Developing DaaS Metrics

    First, don’t try to boil the ocean by measuring all applications at the same time. Instead, choose an application that’s supported by DaaS processes and appoint a specialized team to develop metrics for the application. This team can look many ways—but would likely include stakeholders, developers and other DaaS-supporting roles. Service-level indicators (SLIs) and service-level objectives (SLOs) are also baked into this model, which are chosen to best suit the requirements of an individual application. 

    Once the most valued SLOs of DaaS are determined, the service can be tailored to identify the most critical SLIs. With this knowledge, things like instrumentation, telemetry and analysis requirements can be identified and used to design alerts, dashboards, analyzers and more. Next, setting up policies and procedures around accountability establishes a complete solution. And once the solution for the chosen application is tested, confidence kicks in and creates an easier process for adapting and expanding the process around other applications. 

    This means DaaS can provide many key capabilities to both the organization and the teams who rely on them. A specialized DaaS team can then figure out the best metrics for larger implementation on any application. As a result, SLOs can be evolved for other future applications, to be used as a baseline for future improvements. 

     

  • Datadog Unfurls Application Security Service

    Datadog Unfurls Application Security Service

    Datadog, Inc. today made generally available an Application Security Monitoring (ASM) service that is based on the same agent software that many DevOps teams already use to monitor applications.

    Pierre Betouin, vice president of product for the cloud security platform at Datadog, said ASM is designed to make it simpler for DevOps teams to add additional DevSecOps best practices to their existing workflows. The ASM service is based on a runtime application self-protection (RASP) engine and web application firewall that Datadog gained with the acquisition of Sqreen a year ago.

    ASM then employs distributed tracing to discover code-level vulnerabilities such as server-side-request forgeries (SSRFs), SQL injection and cross-site scripting (XSS) flaws. It is designed to extend an existing Datadog Cloud Security Platform that includes cloud security posture management (CSPM), cloud workload security (CWS) and cloud SIEM services.

    The overall goal is to make it simpler for DevOps teams to address application security by eliminating the need to deploy and maintain a separate set of agents within applications, said Betouin. That approach reduces resistance among DevOps teams that would otherwise be concerned about the additional overhead another approach to application security would add to an application environment, he added.

    The number of organizations looking to implement DevSecOps best practices is expected to increase in the weeks and months ahead in the wake of a series of high-profile breaches and zero-day vulnerability disclosures. Many organizations are now performing security reviews across their entire software supply chain as part of an effort to discover any malicious malware that might have been inserted into applications.

    The challenge those organizations face is that as application environments become more dynamic, maintaining application security becomes more difficult as code is continuously updated. The best way to address that engineering challenge is to extend the reach of an observability platform that many DevOps teams already have in place, noted Betouin. Ultimately, the goal is to automate application security as much as possible but that’s not going to be achievable if DevOps teams lack the context required, he added.

    It’s not clear at what rate organizations are embracing DevSecOps best practices. However, it’s clear that DevOps teams are being held more accountable for application security. Most developers are now charged with becoming application security experts overnight, so the only way to effectively ensure application security is to uncover security flaws before applications are deployed in production environments.

    There are, of course, multiple ways of achieving that goal. Datadog is betting that the path of least resistance is via a cloud service that connects to agent software inserted within those applications. DevOps teams have been inserting agent software, in one form or another, into those applications for years. The issue is that with each new agent added there is yet another software component that needs to be deployed and regularly updated. If not carefully tracked, a DevOps team could find itself attempting to manage an entire portfolio of agent software for every platform employed.

  • Understanding SaaS Security for DevOps

    Understanding SaaS Security for DevOps

    As Software-as-a-service (SaaS) and DevOps adoption grew, new teams were formed to address emerging security challenges. Traditional solutions weren’t built to detect the new vulnerabilities in the cloud and created excessive noise for an already stressed pool of resources.  

    The combination of emerging zero-day vulnerabilities and an avalanche of false-positives ends up increasing security problems and slowing down DevOps projects. The good news is that recent developments in security and visibility are now increasing speed and improving visibility. 

    Gartner forecasted spending on public cloud services would reach $396 billion in 2021 and increase by 22% to reach $482 billion in 2022. SaaS applications based in the cloud have exploded with the market growing 18% each year; 99% of organizations will be using one or more SaaS applications by the end of this year. 

    What does this mean for security, especially for the security of personally identifiable information (PII) and business data in the enterprise? SaaS data includes, but is not limited to, customers’ sensitive PII and payment information; increasingly SaaS applications also house mission-critical enterprise information including product plans, patent information, business and operational processes and human resource records. 

    The extensive data held in SaaS applications presents huge security risks and costs for organizations globally. The average cost of a data breach exceeded $4.2 million, the most in the 17-year history of the IBM Cost of a Data Breach report, and nearly half of the breaches involved compromised PII, the costliest record type to lose, at $180 stolen record—an increase from $146 per record in 2020.

    SaaS Offers New Ways to Do Business but Introduces Significant Risk

    Salesforce is one of the most recognizable and widely used examples of enterprise SaaS software. Recently, analyst Vernon Keenan explained how Salesforce DevOps required guardrails. “Some companies go too fast when it comes to SaaS, DevOps and security, but smart developers and implementers will respect some basic guidelines to keep their product safe.”

    The same is true of other SaaS software platforms and solutions.

    General purpose application security testing solutions aren’t built for SaaS software environments, and often slow down DevOps processes as well as lack the necessary visibility into SaaS environments. Instead, the patchwork of tools must be replaced with a continuous integration and continuous deployment (CI/CD) approach. Specific steps include:

    1. Check all local and remote libraries. Only checking configurations and access controls, which focus mostly on insider threats, misses application vulnerabilities from custom development or app downloads that could open up your SaaS services to external threat actors.
    2. Carefully and routinely check third-party software libraries. If you are only testing source code and ignoring third-party software libraries, you are only securing half of your software application attack surface. CVEs are publicly reported every day on commonly used open source software libraries, showing attackers a direct path to compromise those key components. Running a software composition analysis (SCA) regularly to check all your locally bundled and remotely referenced libraries is a key step in achieving a secure software supply chain.
    3. Don’t assume you’re protected from common vulnerabilities. Static application security testing (SAST) can often miss cross-site scripting (XSS) or SOQL/SOSL injection attacks on SaaS platforms. 

    By identifying security vulnerabilities faster and more accurately, new SaaS security tools can allow organizations to gain the promised benefits of DevOps with better visibility.