devopsy.kinsta.cloud

Author: Mike Vizard

  • Snyk Acquires Helios to Extend Reach of ASPM Platform

    Snyk Acquires Helios to Extend Reach of ASPM Platform

    With its acquisition of Helios, Snyk plans to add an ability to capture application runtime data to extend the capabilities of its application security posture management (ASPM) platform.

    Manoj Nair, chief product officer for Snyk, said Snyk AppRisk will soon provide real-time insights into runtime environments using a Helios observability platform that provides them with deeper insights into issues that need to be resolved. That capability will provide developers with additional context as more responsibility for application security continues to shift left toward application development teams, he added.

    Armed with that insight, it then becomes simpler to prioritize remediation efforts based on the level of risk a vulnerability actually represents to the organization, said Nair. That’s critical to close a longstanding divide between cybersecurity and application development teams that, in the absence of any real ability to determine the severity of a vulnerability, results in developers wasting what limited time they have to allocate to remediation, he noted.

    Nair said the overall goal is to enable organizations to deploy more secure applications while minimizing adverse impacts on developer productivity.

    Snyk last year acquired Enso Security to add an ASPM platform to its portfolio that serves as the foundation upon which Snyk AppRisk was built. It also includes Insights, a Snyk tool that makes use of multiple types of artificial intelligence (AI) models to identify, prioritize and fix vulnerabilities.

    There’s often not a lot of love lost between cybersecurity teams and application developers who typically don’t have a lot of cybersecurity expertise. Most of the issues that cybersecurity teams are tasked to address start with mistakes made by developers that cybersecurity teams then need to convince developers to allocate time to fix.

    Thanks to the rise of DevSecOps best practices, the overall security of software supply chains is improving, but there is still a long way to go before application security truly improves. The one thing that is certain is the level of accountability for vulnerabilities is only going to rise as more stringent regulations go into effect in the months and years ahead.

    In the meantime, DevSecOps teams should assume there will be many more vulnerabilities to remediate. Developers are increasingly using generative AI tools to write code. The challenge is general-purpose large language models (LLMs), such as the one used to drive ChatGPT, were trained using examples of code of varying quality collected from across the web. A lot of the code these platforms generate, not surprisingly, contains vulnerabilities that many developers will not immediately recognize without the aid of some type of scanning tool.

    At the same time, cybercriminals are becoming more efficient at discovering and exploiting vulnerabilities that exist in applications that have already been deployed in production environments. DevSecOps teams should expect that, as a result, more zero-day vulnerabilities requiring immediate attention will soon be discovered.

    One way or another, the percentage of time allocated to application security issues is only going to increase. The only thing left to determine is how best to go about reducing the time and effort needed to make applications as secure as possible.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    SimplyHired.com

    D2 Consulting
    Springfield, Virginia
    DevOps Engineer
    $150,000 to $180,000

    Indeed.com

    Mariner Finance
    Remote
    DevOps Engineer
    $120,000 to $150,000

    ZipRecruiter

    Cogility Software
    Irvine, California
    DevOps Engineer
    $110,000 to $140,000

    CareerBuilder.com

    BAE Systems
    Manassas, Virginia
    DevOps Engineer
    $92,290 to $156,860

    Dice.com

    Rackner
    Falls Church, Virginia
    Software DevOps Engineer
    $90,000 to $140,000

  • SmartBear Acquires Reflect to Gain Generative AI-Based Testing Tool

    SmartBear Acquires Reflect to Gain Generative AI-Based Testing Tool

    SmartBear this week revealed it has acquired Reflect, a provider of a no-code testing platform for web applications that leverages generative artificial intelligence to create and execute tests.

    Madhup Mishra, senior vice president of product marketing at SmartBear, said the platform Reflect created will initially be incorporated into the company’s existing Test Hub platform before Reflect’s generative AI capabilities are added to other platforms.

    Reflect provides access to a natural language interface to create tests using multiple large language models (LLMs) that it is designed to invoke. It can also understand the intent of a test to understand what elements to test regardless of whether, for example, a button has been moved from one part of a user interface to another, said Mishra. Test step definitions, once approved, can also be automatically executed using scripts generated by the platform.

    SmartBear has no plans to build its own LLMs, said Mishra. Rather, the company is focusing its efforts on providing the tools and prompt engineering techniques needed to effectively operationalize them, he added.

    Reflect is the tenth acquisition SmartBear has made as part of an effort to provide lightweight hubs to address testing, the building of application programming interfaces (APIs) and analysis of application performance and user experience. Last year, the company acquired Stoplight to gain API governance capabilities.

    Rather than building a single integrated platform, the company is focused on providing access to lightweight hubs that are simpler to invoke, deploy and maintain, said Mishra. The overall goal is to meet IT teams where they are versus requiring them to adopt any entirely new monolithic platform that requires organizations to rip and replace every tool they already have in place, he said.

    There is little doubt at this point that generative AI will have a profound impact on application testing in a way that should ultimately improve the quality of the applications. As the time required to create tests drops, more tests will be run. Today, it’s all too common for tests not to be conducted as thoroughly as they should be simply because either a developer lacked the expertise to create one or, with a delivery deadline looming, they simply ran out of time.

    Naturally, the rise of generative AI will also change how testing processes are managed. It’s not clear how far left generative AI will push responsibility for testing applications, but as more tests are created and run, they will need to be integrated into DevOps workflows.

    Of course, testing is only one element of a DevOps workflow that is about to be transformed by generative AI. DevOps teams should already be identifying manual tasks that can be automated using generative AI as part of an effort to further automate workflows that, despite commitments to automation, still require too much time to execute and manage. Once identified, DevOps teams can then get a head start on redefining roles and responsibilities as generative AI is increasingly operationalized across those workflows.

  • Diffblue Integrates Generative AI-Based Testing Platform With GitLab

    Diffblue Integrates Generative AI-Based Testing Platform With GitLab

    Diffblue this week generally made available an integration between its automated unit testing platform for Java and the DevSecOps platform from GitLab.

    The Diffblue Cover platform makes use of generative artificial intelligence (AI) to automatically create unit tests based on reinforcement learning technologies that don’t rely on LLMs—avoiding their drawbacks of sometimes introducing hallucinations and also requiring human review.

    Diffblue CEO Mathew Lodge said the integration with the continuous integration capabilities found in the premium and ultimate editions of the GitLab platform would, for example, streamline regression testing in a way that should ultimately improve both application quality and security. Diffblue Cover, for example, can update tests as much as 250 times faster than a human developer can write them manually without developer review.

    That approach also serves to reduce the level of friction many DevSecOps teams encounter when bottlenecks involving testing processes emerge, noted Lodge. The overall goal is to make it simpler for developers to test as much of their own code as possible before integrating it into a build, he added. Otherwise, developers will get fed up because testing is continuously breaking the build, noted Lodge.

    Ultimately, instead of having to write unit tests, developers become supervisors of a platform that automatically generates them on their behalf, said Lodge. The job of a developer doesn’t go away, but it does fundamentally change, he added.

    To achieve that goal, developers need to be able to access a platform that writes the tests and can then also execute them automatically. If it takes too long to create the test, chances are high that most developers won’t run it. On average, writing and evaluating a single unit test can take a developer 10 minutes. Over the course of any project, thousands of tests need to be written, so the amount of time testing takes away from coding is often much greater than most IT leaders fully appreciate.

    Automating those tests should improve developer productivity as more time is available to focus on writing code rather than testing. That doesn’t necessarily eliminate the need for a dedicated testing team, but it does mean that more tests will be run without slowing down the overall pace of application development.

    Developers naturally want to be able to test code at the very instant they create it. AI platforms can make that happen by, for example, employing reinforcement learning to write unit regression tests.

    Most developers are not going to resist assuming more responsibility for testing if the tools to automate that task are more accessible. Instead of merely shifting responsibility for testing left toward developers, DevOps teams need to find ways to streamline the process. Otherwise, testing just becomes one in a series of tasks that are being shifted to developers in ways that many of them are coming to resent.

    It may take some time before AI is fully integrated into software engineering but it’s clear with each passing day more previously manual tasks are being automated. Among the lowest hanging fruit for applying AI to software engineering are clearly testing processes that, if truth be told, few indeed enjoy conducting.

  • New Relic Adds Ability to Correlate IT Events to Business Processes

    New Relic Adds Ability to Correlate IT Events to Business Processes

    New Relic this week added an ability to enable DevOps teams to better understand the potential business impact any change to an IT environment might have.

    Manav Khurana, chief product officer for New Relic, said New Relic Pathpoint adds a dashboard to the company’s observability platform through which business metrics can be collected alongside telemetry data. That data is collected either via connectors provided by New Relic or via a metrics application programming interface (API) that IT teams can invoke.

    IT teams can use that API to connect to custom applications or an end-to-end business process, noted Khurana.

    All that data is then modeled alongside DevOps telemetry data to provide insights into the impact any change might have on the business in real-time, he added. That approach provides the added benefit of making it easier to strategically align the management of applications, services and infrastructure by business function, noted Khurana.

    In the near future, New Relic will also extend the natural language capabilities it is currently previewing to New Relic Pathpoint, he said.

    Longer term, New Relic is working toward making it possible to model how proposed changes to business processes will impact IT environments, added Khurana.

    Business and IT leaders intuitively understand that every business event creates a corresponding IT event, but most organizations manage those processes in isolation. New Relic Pathpoint presents an opportunity to close a divide between IT teams and the rest of the business that has plagued organizations for decades.

    It may be a while before advances in data analytics and AI eliminate that divide completely, but creating a common set of metrics for managing business and IT processes is a crucial first step.

    In the meantime, DevOps teams, in addition to accelerating the pace at which applications can be built and deployed, are being asked to employ observability platforms such as New Relic One to minimize disruption to the business. Observability has always been a core DevOps tenet, but achieving and maintaining it is challenging. Most DevOps teams today aspire to be able to maintain some level of continuous monitoring. However, as it becomes easier and less costly to instrument applications using open source agent software, interest is rising in observability platforms that simplify the investigation of anomalies indicative of an issue that could disrupt an application environment. As that shift occurs, more organizations will seek to correlate IT and business events.

    It’s still early days as far as the adoption of observability platforms is concerned, but it’s apparent that as application environments become more complex, the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. It’s not uncommon for DevOps teams to have multiple monitoring tools that surface a set of predefined but often conflicting metrics. Observability platforms, however, unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue, hopefully before any catastrophic disruption can occur.

  • Survey: Widespread Inability to Remediate App Vulnerabilities

    Survey: Widespread Inability to Remediate App Vulnerabilities

    A survey of 621 IT and security professionals published this week found only 20% are confident in their ability to detect a vulnerability before an application is released.

    Conducted by the Ponemon Institute on behalf of Security Journey, a provider of cybersecurity training services for developers, the survey finds 61% struggling to remediate vulnerabilities effectively, with 55% blaming misalignment between development, security and compliance teams for delays.

    A third of respondents (33%) said teams lacked a common view of applications and assets, with 38% acknowledging they lack the ability to hold departments accountable for patching applications. Only 11% of organizations believed they patch vulnerabilities effectively in a timely manner, the survey finds.

    In the 12 months prior to the study, 54% of respondents suffered a security incident due to an unpatched vulnerability, with 51% experiencing more than eight incidents.

    Overall, half (50%) admitted they fail to test the security of their applications after they have been released. Only 36% specifically teach developers to write secure code. Just one-fifth (21%) educated developers on vulnerability remediation. Less than half (43%) have invested in training provided by a third party.

    When training is provided, 68% of respondents also admitted immediate feedback is not provided and less than half (47%) said secure coding training is customized to meet developer needs. Half (50%) of those who provided training have no formal assessment to measure knowledge gain, the survey found.

    Amy Baker, chief marketing officer and security education evangelist for Security Journey, said the survey makes it clear much work still needs to be done in terms of teaching developers how to write secure code.

    In addition, too many software development teams are overly optimistic about their ability to remediate known vulnerabilities the next time they plan to update an application, said Baker. Many developers move on to the next application simply because either the pressure to meet delivery deadlines is too intense or there is some other emerging technology, such as large language models (LLMs), that needs to be learned, she added. In fact, too many organizations are far too focused on the rate at which applications are built and deployed at the expense of cybersecurity, Baker noted.

    That’s especially problematic because cybercriminals have become much more adept at monitoring application deployments and updates, she added.

    The amount of time between when code is deployed and when cybercriminals begin scanning it for vulnerabilities is now measured in hours rather than days. Developers, unfortunately, are deploying more insecure code than ever. In fact, much of that code is insecure by design, noted Baker.

    Overall, nearly half of respondents (48%) only train developers annually, bi-annually or when an incident occurs. More than two-thirds (68%) only train developers on how to implement secure coding practices to meet compliance requirements. In effect, because developers are not taught security in school, what training they do receive is on the job, said Baker.

    Clearly, there is still much work to be done when it comes to implementing DevSecOps best practices to improve application security. In the meantime, the amount of code that needs to be patched has already reached proportions that most application development teams are never going to be able to effectively address.

  • Venafi Adds Ability to Prevent Unauthorized Code From Running

    Venafi Adds Ability to Prevent Unauthorized Code From Running

    Venafi added an ability to prevent unauthorized code from running in IT environments that make use of its machine identity management platform.

    Shivajee Samdarshi, chief product officer at Venafi, said the Stop Unauthorized Code Solution leverages the company’s CodeSign Protect offering to ensure that only authorized code can run on any given platform.

    The overall goal is to enable organizations to better secure their software supply chains using a zero-trust approach to software based on identity management and code signing to verify software comes from an approved source and complies with policy controls, he added.

    All code is signed using private digital certificates or those issued by trusted certificate authorities, said Samdarshi. Before code can execute, the security platforms an organization has in place can be configured to check that digital signature against trusted code signing certificates, he noted.

    Interest in securing software supply chains has risen sharply since the Biden administration issued an executive order requiring federal agencies to implement a range of measures, including code signing, to achieve that goal. However, securing software chains is often more challenging than organizations initially appreciate.

    In fact, a recent Venafi survey found that 70% of security and IT leaders believe that software supply chain attacks are their biggest security blind spot. Additionally, 85% believe that continuous security validation of the CI/CD pipeline is vital to reduce the risk of vulnerabilities going undetected during the software development lifecycle. A full 88% said they believe machine identity management is essential to the success of zero-trust models that are being more widely adopted across enterprise IT environments.

    Arguably, the most important thing organizations need to focus on is making sure application developers and cybersecurity professionals develop a working relationship. The biggest barrier to the adoption of DevSecOps best practices required to secure software supply chains remains largely cultural. For more years than anyone cares to admit, many developers have viewed cybersecurity more as a hindrance to application development that needs to be overcome or circumvented rather than being a core aspect of a quality assurance process. The total number of vulnerabilities that exist in applications running in production environments could likely be measured in the billions.

    Remediating all those vulnerabilities may never be practical, but at the very least, DevSecOps teams could make sure that no new code containing vulnerabilities is allowed to execute. Cybercriminals have become especially adept at inserting malware into code that they hope will find its way into any number of downstream applications before they activate it. That capability alone should help mollify cybersecurity teams that are increasingly being tasked with improving software supply chain security. The challenge is those cybersecurity teams don’t always appreciate the impact new policies can have on the pace at which applications are developed and deployed.

    Like it or not, software supply chains will generally be more secure in 2024. The only thing that remains to be determined is how much friction will be injected into DevSecOps workflows to achieve that goal.

  • Mobb Extends DevSecOps Reach of Tool to Generate Patches

    Mobb Extends DevSecOps Reach of Tool to Generate Patches

    Mobb today added an ability to instantly surface patches for vulnerabilities at the time when code is being committed during a DevSecOps workflow.

    Previously, the tool provided by Mobb to create validated patches based on the scan results of third-party SAST tools would only surface issues to individual developers.

    Mobb CEO Eitan Worcel said organizations can now address these issues within the context of DevSecOps workflow.

    The Mobb platform combines proprietary security research and traditional semantic analysis with generative artificial intelligence (AI) to automatically create patches for vulnerabilities. The overall goal is to make it simpler for DevSecOps teams to consistently ensure applications with known vulnerabilities are remediated before they are deployed, said Worcel.

    The Mobb approach eliminates the need for IT teams to sort through static application security testing (SAST) scans themselves. Each vulnerability typically requires at least 30 minutes to fix, so the Mobb platform improves application security while simultaneously making developers more productive.

    Historically, one of the reasons for the wide divide between application development teams and cybersecurity professionals is that many of the vulnerabilities discovered don’t actually impact applications running in production environments. Development teams then find themselves wasting time investigating vulnerabilities and, when they do determine a vulnerability is an issue, spending time developing a patch. The Mobb tool automatically creates the necessary patch, so there is less of a need to debate which vulnerabilities are worthy of the time required to create a patch.

    For decades, application development teams have been attempting to find a way to remediate vulnerabilities as quickly as possible. With increased focus on adopting DevSecOps best practices to address those vulnerabilities, more organizations are now reviewing software supply chains as part of a larger effort to improve application security.

    There will, of course, be vulnerabilities that the Mobb tool will not be able to address simply because there may not be enough affected applications to warrant pre-building a patch. Even with the most robust set of rules, it is improbable that an automated tool can, with 100% certainty, safely fix every issue. However, given the number of routine vulnerabilities present in applications, such as SQL injections, there’s plenty of opportunity to improve developer productivity by relying on patches that address common vulnerabilities.

    The process by which patches are prioritized, developed and then applied has, of course, long been a source of DevOps frustration. Anything that streamlines that process will go a long way toward improving the overall state of application security at a time when cybercriminals are becoming more adept at exploiting vulnerabilities. The challenge is finding a way to remediate vulnerabilities that developers will embrace rather than resist. The Mobb approach still provides them with control over what patches are applied but the toil involved with creating a patch in the first place has been substantially reduced.

    It’s not clear how long it might be before automated approaches to building patches might improve the overall state of application security but, as always, every journey needs to begin with a first step in the right general direction.

  • Legit Security Applies AI to Detect Vulnerable Application Secrets

    Legit Security Applies AI to Detect Vulnerable Application Secrets

    Legit Security today announced it has expanded the scope of its application security posture management (ASPM) platform to make use of artificial intelligence (AI) to discover secrets more accurately in applications that cybercriminals can actually exploit.

    Scanners typically generate high false positive rates to the point where developers often start to ignore them. As a result, it’s not uncommon for secrets to be discovered in an application even though an alert was generated.

    Legit Security CTO Liav Caspi said the company is now applying a large language model (LLM) specifically trained for source code along with prompt engineering techniques and heuristics to reduce the level of alert noise that developers would otherwise see when scanning for secrets. The overall goal is to correctly identify access keys, passwords, application programming interface (API) keys and other personally identifiable information (PII) that should not be exposed once an application is deployed in a production environment, he noted.

    That capability can be applied to detect secrets across all development assets, including code repositories, source code management (SCM) tools, build tools and logs, artifacts and private and public documentation. In addition, this approach also uncovers toxic combinations of secrets or ones that might lie buried within assets such as source code history or modified Confluence pages that developers often forget exist, noted Caspi.

    Legit Security also enables DevSecOps teams to apply preventive guardrails on developer endpoints using the Legit command line interface (CLI) to stop secrets from being exposed before code is pushed. In addition, automated workflows can reach developers as part of a pull request or create Slack messages or Jira tickets to streamline remediation. DevSecOps teams can also continuously triage results to create a baseline that includes exceptions.

    As part of a larger effort to secure software supply chains, Legit Security has developed a software-as-a-service (SaaS) platform designed to apply security policies across an entire software development life cycle. The company is now extending the capabilities of that platform using AI technologies to detect secrets in both source code and all the components that make up a development pipeline as they are added.

    In the wake of an executive order requiring federal agencies to better secure software supply chains, there is now more focus than ever on application security. Unfortunately, many developers are a little too cavalier when it comes to managing secrets during the application development process. They often leave secrets in plain text to facilitate workflows, but more often than many care to admit, those secrets are not removed before an application is deployed. Knowing this, cybercriminals have learned to scan applications for those exposed secrets. Once gained, they then appear to be just another legitimate user of an application that might not be discovered until malware is activated.

    It may be a while before the cultural and technical issues that conspire to make the software supply chain insecure are fully addressed. In fact, the problem may get worse before it gets better—simply because the pace at which distributed applications are being built and deployed only continues to accelerate. At the same, the cost of making a secrets mistake is also only going to increase as regulations become more stringent. In fact, it’s now only a matter of time before stiff fines intended to make an example of one or more unfortunate organizations are eventually going to be levied.

  • Chronosphere Acquires Calyptia to Process Log Data More Efficiently

    Chronosphere Acquires Calyptia to Process Log Data More Efficiently

    Chronosphere today announced it has acquired Calyptia to add additional pipeline management capabilities to its observability platform.

    Calyptia created Fluent Bit and Fluentd, a set of open source log processors that are now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    Chronosphere CEO Martin Mao said these log processors will be embedded into the company’s namesake observability platform to enable the routing, transformation and optimization of log data at scale. That issue has become problematic because cloud-native applications based on microservices create exponentially more telemetry data than legacy monolithic applications. If it becomes too costly to analyze that data, then DevOps teams will begin to limit the number of applications they will observe, noted Mao.

    The Calyptia platform achieves that goal using filters at the data source to reduce the volume of data that might otherwise be shared by 30% or more.

    The shared data can then be analyzed in real time rather than waiting for it to be stored and indexed. In addition, DevOps teams can enrich that data in flight to include additional context.

    Calyptia cofounder Anurag Gupta added that the primary mission for the company has always been to make log data more accessible to developers as they build and deploy applications.

    The acquisition of Calyptia comes on the heels of a log management alliance between Chronosphere and CrowdStrike through which a log storage and virtualization capability, dubbed Logs powered by CrowdStrike, has been added to the observability platform. The overall goal is to simplify the management and analysis of logs via a single click of a graphical tool or within the context of a larger DevOps workflow based on a command line interface (CLI) without requiring data engineering expertise, said Mao.

    It’s not clear how fully DevOps teams have embraced observability, but it’s apparent the legacy monitoring tools that collect a set of predefined metrics are not able to keep pace with the complexity of cloud-native application environments. An observability platform makes it simpler to query log data and discover the root cause of an issue—hopefully before a catastrophic event occurs. The challenge, of course, is providing that capability without incurring massive increased storage costs for log data.

    Despite those concerns, the need for observability is becoming a more pressing issue with each passing day. Organizations have never been more dependent on applications to drive revenue. A degradation in performance is usually an early indicator of a disruption that often has a direct impact on revenue and profitability.

    There is, of course, already no shortage of observability platforms. The issue most DevOps teams encounter is finding the funding needed to employ one at a time when organizations have become much more sensitive to IT costs. There may be an opportunity to rationalize some monitoring tools to help pay for the cost of a more modern observability platform, but regardless of approach, an ounce of prevention is always going to be worth a pound of proverbial cure.