devopsy.kinsta.cloud

Author: Mike Vizard

  • OpenText Extends Tool for Auditing Source Code Using Machine Learning

    OpenText Extends Tool for Auditing Source Code Using Machine Learning

    OpenText this week updated a static analysis tool it provides to audit code using machine learning algorithms to provide deeper insights into on-premises IT environments.

    Announced at the OpenText Security Summit 2024 conference, the latest generation of Fortify Audit provides additional artificial intelligence (AI) models capable of learning the unique attributes of custom source code.

    The latest version of Fortify Audit Assistant also adds the ability to detect drift in a model and, if necessary, automatically refresh it. OpenText is now committing to refreshing those models every quarter.

    The discriminant AI model from OpenText enables machine learning algorithms to learn how humans conducted an application audit to then run similar tests on other applications. Previously, Fortify Audit relied on the same core model to audit both on-premises and software-as-a-service (SaaS) applications based on data collected by OpenText. Fortify Audit Assistant now provides support for more than 30 language-specific models to improve testing performance.

    Dylan Thomas, senior director for Fortify engineering and product for OpenText Cybersecurity, said this capability ensures that any sensitive data never leaves an on-premises IT environment.

    The overall goal is to streamline the number of alerts that would otherwise overwhelm a DevSecOps team trying to identify the root cause of an issue, he added. For example, Fortify Audit Assistant will identify test code that is not vulnerable because it was never deployed in an actual production environment. That approach makes it easier for DevOps teams to prioritize which vulnerabilities to fix first in their source code using a lightweight AI model that still enables them to deeply scan source code, noted Thomas.

    Historically, DevSecOps teams need to make a trade-off between lightweight approaches and deep scans of source code that is no longer required, he added.

    As regulations pertaining to software supply chain security become more stringent the number of development teams that will be subject to some type of audit is only going to increase. The cost of failing an audit will also inevitably increase as regulatory bodies look to make examples of organizations that are not properly securing their software supply chains.

    It’s not clear how aggressively organizations are embracing best DevSecOps practices to address myriad software supply chain security issues that were highlighted in an executive order issued by the Biden administration to Federal agencies. However, with the rise of AI and other forms of automation, it should become simpler to identify more vulnerabilities before they wind up being exploited in a production environment.

    There will always, of course, be a need to secure production environments because there’s always a probability mistakes will be made. However, given the lax practices many organizations have employed to build and deploy applications, it’s probable the number of vulnerabilities that exist in production environments today is beyond counting. In many cases, the better part of valor might be to replace many of those applications entirely with ones built using DevSecOps best practices.

    Regardless of the path to better application security chose the one thing that is certain is cybercriminals are only going to become even more adept at discovering those vulnerabilities.

  • Salesforce Adds Ability to Apply Custom Security Policies to APIs

    Salesforce Adds Ability to Apply Custom Security Policies to APIs

    Salesforce today added the ability to customize security policies for application programming interfaces (APIs) to the Mulesoft Anypoint API management platform.

    Gerry Egan, vice president of product management for Mulesoft at Salesforce, said this capability makes it possible for organizations to use an Anypoint Flex Gateway Policy Development Kit to streamline development of custom API security policies that can be implemented as code.

    In addition to providing integrations with integrated development environments (IDEs), the Anypoint Flex Gateway Policy Development Kit also provides test policies that can be employed to ensure API security.

    That approach makes it simpler to ensure APIs are secure as they are being built and deployed within the context of an automated DevOps workflow versus having to rely entirely on a separate API security platform, he noted.

    The Mulesoft Anypoint Gateway already comes with security policies that DevSecOps teams can readily implement. Salesforce is now adding the ability to apply custom policies that DevOps teams can apply as it becomes apparent cyberattacks against APIs are becoming more sophisticated, noted Egan. Those policies can, for example, be used to remove sensitive data or replace it with a token, he added.

    Responsibility for API security is often not well established in many organizations, but as more accountability for API security shifts left toward DevSecOps teams, there is growing interest in addressing the issue as code when APIs are developed and deployed. While cybersecurity teams are responsible for maintaining cybersecurity after APIs are deployed, few of them have any insight into how an API is crafted. That’s a significant issue because cybercriminals have become more adept at both exfiltrating data via external facing APIs in addition to manipulating the underlying business logic to compromise a digital process, noted Egan.

    The Mulesoft Anypoint Gateway automates the process of building and applying security policies to APIs as part of the software development life cycle (SDLC) in a way that minimizes any impact on developer productivity, he added. That approach provides the added benefit of reducing the level of cognitive load developers would otherwise experience if they had to manually create software policies, said Egan.

    In general, most APIs are internally facing, but it’s not uncommon for them to suddenly be exposed to the internet as application use cases evolve. The best way to ensure API security is at the point of creation. Providing developers with API security tools gives them an opportunity to address security issues at the beginning of the application development process.

    There have already been several cybersecurity breaches involving APIs in the past year. It may only be a matter of time before there are additional breaches that could prove catastrophic. Regardless of the size of the API breach, the application development team that created and deployed the API in the first place is ultimately going to be held accountable for fixing it. The challenge is to find the simplest way to eliminate the issue in the first place at a time when the number of APIs being built and deployed only continues to explode.

  • IBM Adds Lower-Cost Linux Mainframe to Portfolio

    IBM Adds Lower-Cost Linux Mainframe to Portfolio

    IBM today made its most aggressive move yet in its quest to make mainframes running Linux more affordable, launching an entry-level platform starting at $135,000.

    The IBM LinuxONE 4 Express is a pre-configured rack system that is based on the same 5.2Ghz IBM Telum processor that IBM uses in its Z16 series of mainframes.

    In addition, the platform supports IBM Secure Execution, which is designed to thwart any attempt to decrypt data in the future using quantum computers.

    IBM claims organizations that move Linux workloads from x86 servers to an IBM LinuxONE 4 Express can save over 52% on their total cost of ownership over five years.

    The overall goal is to make it simpler for organizations to consolidate workloads that otherwise would need to be deployed across a distributed computing environment, she added. That approach ensures higher levels of availability for workloads that are increasingly processing massive amounts of data using two levels of physical and two levels of virtual cache in a way that consumes less energy, noted Tina Tarquinio, vice president of product Management for IBM Z and LinuxONE.

    The IBM LinuxONE 4 Express also includes an integrated accelerator for running artificial intelligence (AI) inference engines using more than 6 TFLOPs compute capacity per chip.

    IBM expects that as more organizations process sensitive data to drive AI applications, there will be increased interest in deploying applications in more secure on-premises IT environments, said Tarquinio. Mainframes provide a more cost-effective way to achieve that goal at a time when DevOps teams are embracing methodologies such as platform engineering to centralize the management of workloads, she added.

    At the same time, increased reliance on automation is making it simpler for IT teams to rely on multiple types of platforms to optimally process workloads. That capability enables IT teams to make platform decisions that are based on fit-for-purpose best principles more easily, noted Tarquinio.

    It’s not clear how many organizations will now be able to afford a mainframe when the initial cost of an x86 server is still much lower. But in the face of ongoing economic uncertainty, it seems more organizations are willing to consider all their options. The issue is that adding additional X86 servers is often viewed as the path of least resistance to increasing compute capacity.

    Naturally, each IT team will need to decide what path forward makes the most sense for them, but as workloads continue to become more data-intensive, it’s clear that infrastructure requirements are changing. The more data that needs to be processed, the more challenging it becomes to maintain service level agreements that are based on maintaining specific levels of application performance, noted Tarquinio.

    The challenge now is determining where best to run those workloads across an increasingly hybrid cloud computing environment that continues to offer more options as IT platforms evolve and expand.

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

    Dice.com

    Travelers
    Hartford, Connecticut
    DevOps Tech Lead
    $133,500 to $220,300

    Indeed.com

    Lawrence Berkeley National Laboratory
    San Francisco, California
    Identity and Access Management DevOps Engineer
    $126,900 to $214,140

    SimplyHired.com

    Workday
    Pleasanton, California
    Software Development Engineer
    $112,500 to $204,000

    LinkedIn

    IBM
    Denver, Colorado
    DevOps Engineer
    $110,100 to $161,100

    CareerBuilder.com

    Cognizant Technology Solutions
    Oakdale, New Jersey
    DevOps Manager – Technology Modernization
    $95,500 to $212,600

  • Graylog Makes Free API Security Tool Available to Developers

    Graylog Makes Free API Security Tool Available to Developers

    Graylog this week made available a free version of its platform for securing application programming interfaces (APIs), intended to encourage developers to adopt best practices to secure them.

    The free version of Graylog API Security has all the capabilities of the paid version but is limited to 16GB of local rolling storage on a single node with a one-year renewable license.

    Graylog CEO Andy Grolnick said the goal is to make it simple for developers to use this edition of the platform as they are building APIs. As applications are deployed in a production environment, the expectation is organizations will then need to access the version of the platform that is designed to scale, he added.

    Based on technology Graylog gained with the acquisition of an API security platform originally developed by Resurface.io, this free version of Graylog’s API security platform is trying to help bridge the divide between the application development teams that create APIs and the cybersecurity teams tasked with protecting them, said Grolnick.

    Capabilities of the platform include API classification, discovery, risk scoring, an ability to capture API request and response payloads and continuous monitoring of API and threat signatures in real-time. Collectively, these capabilities enable Graylog API Security to provide high-fidelity alerts using a data lake that is embedded in the platform, noted Grolnick.

    That approach enables Graylog API Security to capture all API requests and response details to distinguish valid API traffic from malicious activity involving, for example, data exfiltration hiding under valid response codes.

    In addition, Graylog API Security automatically surfaces remediation guidance for developers who typically lack cybersecurity expertise.

    API security has become a major DevSecOps issue because cybercriminals are increasingly targeting APIs to steal data. As more externally facing APIs are deployed, the overall size of the attack surface that needs to be defended increases exponentially.

    A recent survey conducted by Enterprise Strategy Group (ESG) on behalf of Graylog found more than three-quarters of respondents (76%) have an average of 26 APIs per application. Most respondents are using open APIs for public consumption (67%) or are connecting applications with partners (64%).

    In general, most of those APIs are internally facing, but it’s not uncommon for those APIs to suddenly be exposed to the internet as use cases for applications evolve. The challenge is that few cybersecurity teams have visibility into APIs that, when manipulated by malicious actors, can expose code or provide a mechanism through which business processes can be compromised. This issue often exists because, in many organizations, it’s still not clear who is actually responsible for API security.

    Arguably, the best way to ensure API security is at the point of creation. Providing developers with API security tools gives them a chance to do the right thing from the beginning of the application development process, said Grolnick.

    There have already been several cybersecurity breaches involving APIs in the past year. It may only be a matter of time before there are additional breaches that could prove catastrophic. Regardless of the size of the API breach, the application development team that created and deployed the API in the first place is ultimately going to be held accountable for fixing it.

  • OX Security Optimizes DevSecOps to Improve Application Security

    OX Security Optimizes DevSecOps to Improve Application Security

    OX Security this week updated its application security posture management (ASPM) platform to enable DevSecOps teams to instantly identify applications running in production environments that are running code that could be potentially exploited.

    The ASPM platform from OX Security leverages large language models (LLMs) to identify vulnerabilities. The latest version adds an ability to confine the number of alerts generated to instances of code that can actually be exploited.

    OX Security CEO Neatsun Ziv said that approach reduces the number of alerts that would otherwise be generated by 99% to enable DevSecOps teams to focus their limited resources on the 1% of alerts that represent an actual risk to the business. OX Security achieves that goal in part because its scanners are integrated with source control, continuous integration/continuous delivery (CI/CD) platforms, registries and cloud computing environments.

    The overall goal is to reduce the amount of manual effort currently required to consistently maintain DevSecOps best practices.
    The primary reason many vulnerabilities are never addressed is that DevSecOps teams are simply overwhelmed by alerts. Most of the alerts generated by a cybersecurity team are not immediately relevant because either the vulnerability is not present in the application running in a production environment or the application doesn’t connect to the internet.

    The OX Security platform makes it possible to identify application security issues that need to be prioritized because it has been confirmed a vulnerability exists that can be exploited, said Ziv.

    No matter how precise the alert process becomes, a DevSecOps team will still need to manage it, added Ziv. However, as the alerts generated become more relevant, it should become easier to bridge the historic divide between application developers and cybersecurity teams. Too many developers routinely ignore vulnerabilities identified by cybersecurity teams simply because previous efforts to identify the actual severity they represent have ultimately been a waste of their time.

    The challenge just about any organization encounters when trying to better secure their software supply chains is, not surprisingly, getting application developers to buy into the DevSecOps process. Most developers are going to actively resist any approach to remediating vulnerabilities that takes time away from building new applications. Most of them only allocate about 10% of their time or less to remediating vulnerabilities. As such, it’s incumbent on a DevSecOps team to find ways to address application security issues in ways that don’t adversely impact developer productivity.

    Organizations could mandate that vulnerabilities be remediated. In fact, there is a growing body of regulations that will require organizations to do just that unless they can prove the vulnerability in question cannot be exploited. The only way to effectively make that case will be to rely more on automation to document that the code running in a production environment is actually secure.

    In the meantime, developers should expect to see their code scrutinized more than ever. Of course, the better part of valor is to ensure that as many vulnerabilities as possible are never introduced.

  • Cycode Discloses GitHub Actions Vulnerability in Google Bazel Project

    Cycode Discloses GitHub Actions Vulnerability in Google Bazel Project

    Cycode today revealed it discovered a command injection vulnerability in the way the GitHub Actions continuous integration/continuous delivery (CI/CD) platform was used to update the open source Bazel project that many organizations employ to build and test software.

    The vulnerability, now remediated, could have been used to create a backdoor through which malicious code could have been inserted into a codebase that is managed by Google.

    Cycode researchers shared their discovery with Google, which has since updated the way it employs GitHub Actions to manage the Bazel codebase. Specifically, Google updated the base permissions to embrace least privilege principles to resolve the vulnerability discovered by Cycode.

    The vulnerability was discovered using RAVEN, an open source tool for scanning CI/CD platforms for vulnerabilities that Cycode makes available.

    Elad Pticha, senior security researcher for Cycode, said the vulnerability is the latest example of an instance of an open repository for building software that has been shown to be potentially vulnerable to an attack on a software supply chain that could theoretically impact any number of downstream applications and projects, including Kubernetes, Angular and platforms and services provided by Uber and LinkedIn.

    A Custom Actions capability that enables application development teams to create their own workflows presents any cybercriminal attempting to compromise of software supply chain with a tempting target, noted Pticha. A few changes to lines of code in a workflow can translate into thousands or even millions of lines of code, many of which an organization may never detect. Out of 3.4 million workflows examined by Cycode, nearly all (99%) make use of one or more Custom Action.

    Cycode has previously identified dozens of vulnerabilities in open source projects by mainly focusing on vulnerabilities within workflows. This latest research shows those vulnerabilities extend to indirect dependencies, such as Custom Actions, noted Pticha.

    Each DevOps team should review its own workflows for similar vulnerabilities at a time when more cybercriminals than ever are intent on compromising software supply chains. While many organizations have embraced DevSecOps workflows to improve application security, there is a natural tendency to overlook vulnerabilities that might exist in the workflows used to build and deploy software. The challenge is that DevSecOps workflows are still immature. A recent survey of 500 U.S. CISOs, AppSec directors and DevSecOps team members conducted by Cycode found 78% admitted application security attack surfaces are unmanageable, with 90% acknowledging relationships between their security and development teams need to improve.

    It’s not apparent if the vulnerability discovered by Cycode was actually ever exploited, but as most cybersecurity professionals know, if it can be imagined, someone has tried it. As such, any organization that uses Bazel might be well-advised to conduct a code review.

    In the meantime, it’s already apparent that regulations pertaining to securing software supply chains are only going to become more stringent in the months ahead. In the wake of the executive order from the Biden administration requiring federal agencies to lock down their software supply chains, it’s now only a matter of time before similar requirements are baked into legislation and various other regulations are implemented. The challenge and the opportunity now is to get ahead of this issue before a mandate with a hard deadline that can’t be ignored winds up disrupting the entire software development life cycle.

  • Dynatrace Extends Data Reach and Scope of Observability Platform

    Dynatrace Extends Data Reach and Scope of Observability Platform

    At its Perform 2024 event today, Dynatrace unfurled a Dynatrace OpenPipeline that makes it possible to apply analytics to multiple types of data sources in real time.

    The company also unveiled a Data Observability offering that can be used to vet the quality and lineage of data being exposed to the Davis artificial intelligence (AI) engine at the core of the Dynatrace observability platform to reduce false positives that otherwise might generate an alert in addition to helping reduce the volume of data that might need to be stored.

    Finally, Dynatrace announced it is starting today extending the reach of its observability platform to the large language models (LLMs) that are used to create generative AI platforms. That capability will, for example, make it simpler to monitor the consumption of tokens that are used to provide access to these models.

    Steve Tack, senior vice president for product for Dynatrace, said Dynatrace OpenPipeline will enable organizations to streamline the collection of data in a way that will enable them to apply observability more broadly by applying stream processing algorithms to petabytes of data.

    Scheduled to be available in 90 days, the Dynatrace OpenPipeline capability enables IT teams to ingest and route observability, security, and business events data from any source and in any format at the point of ingestion, including unstructured data that is automatically converted into a usable format. That data can then be enriched to enable deeper analytics.

    It also provides IT teams with more control over which data they analyze, store or exclude from analytics, which in turn helps reduce the total cost of observability, noted Tack.

    Finally, it presents IT teams with the ability to apply more customizable security and privacy controls to how that data is employed, he added.

    Dynatrace is pursuing a multimodal approach to AI that spans predictive, causal and generative models. Collectively, that approach makes it simpler to identify the root cause of issues, identify anomalies that might disrupt services and streamline incident management by, for example, providing summarizations of events in a natural language format.

    It’s not clear how broadly observability will be applied beyond the data collected to manage DevOps workflows and other IT processes, but it’s clear there is a high correlation between IT events and business outcomes as organizations become more dependent on software. As AI becomes more pervasively employed, it should become simpler to apply analytics to a much wider range of types of data to surface the relationship between IT events and business processes. In effect, Dynatrace is making it simpler to apply best data engineering practices to collect, manage and analyze that data, noted Tack.

    In the meantime, DevOps teams should revisit how their pipelines are currently constructed to make it simpler to capture all relevant data. As critical as telemetry data collected from the DevOps platform is to ensure application development and delivery occurs as fast as possible, that data is only one factor in a larger equation. The challenge and the opportunity now is determining how best to apply AI to correlate it all.

  • Anima Adds Ability to Personalize Generative AI Code

    Anima Adds Ability to Personalize Generative AI Code

    Anima today revealed is has added an ability to personalize the code its generative artificial intelligence (AI) platform creates based on how an application is described using tools from Figma and Adobe.

    That capability makes it possible for the code being generated to resemble the coding style of an organization or specific developer more closely.

    Anima CEO Avishay Cohen said the company developed this capability to reduce the editing time that is otherwise required when trying to embed code generated by a large language model (LLM) within an application that has a well-defined coding methodology.

    The platform that Anima provides is based on a mix of LLMs and heuristics that the company developed to generate code. In this case, the code being generated is written in React or HTML to make it simpler to build an application’s front end. In contrast, a general-purpose LLM such as ChatGPT is not optimized for creating these types of graphical applications.

    Developers no longer need to worry about, for example, making sure each pixel is perfectly placed because the Anima platform automates that part of the application development process, including adding responsive behavior, animations and logic, noted Cohen. In addition, customized instructions may be applied to an entire project or even a specific component.

    In effect, the platform enables backend developers to automatically create a front-end for their application from a description in tools provided by Figma or Adobe. As a result, developers can allocate more time to writing business logic and optimizing application performance, said Cohen.

    Later this year, Anima will integrate its platform with GitHub and other continuous integration/continuous delivery (CI/CD) platforms as part of an effort to extend the reach of the platform across an entire codebase, he added.

    There is, of course, already no shortage of generative AI tools for writing code, but the degree to which they have been incorporated into DevOps workflows varies from one organization to the next. Much of the code created using platforms such as ChatGPT can vary widely in terms of quality. These platforms were trained using code collected from across the web so it’s not uncommon for the code generated to include known vulnerabilities that DevOps teams need to scan before incorporating into a build. In other cases, the code generated might simply break when installed.

    Regardless of these issues, however, the amount of code being generated by machines is only going to increase, especially as more LLMs that are specifically trained to create code based on examples that have been closely vetted become more widely available.
    In the meantime, developers who never especially enjoyed building the visual front ends of applications can now focus more of their time on tasks they prefer. Alternatively, developers who specialize in the front ends of applications will find that much of the toil involved will soon be automated in a way that should provide more time for them to create customized experiences.

    One way or another, the overall pace at which applications are built is about to exponentially increase. The challenge now will be finding ways to take advantage of AI to enable DevOps teams to keep pace.

  • CloudBolt Commits to Applying AI to FinOps

    CloudBolt Commits to Applying AI to FinOps

    CloudBolt Software today revealed it plans to infuse artificial intelligence (AI) into the financial operations (FinOps) capabilities it provides via its IT management platform over the coming year.

    Kyle Campos, chief product and technology officer for CloudBolt, said given the inherent complexity of modern IT environments, there is a need to apply machine learning algorithms and other forms of AI to enable IT organizations to apply policies in real-time to reduce costs. That capability is especially critical in cloud computing environments where services are often invoked by developers with little to no oversight, he noted.

    FinOps is a discipline that promotes a shared responsibility for an organization’s cloud computing infrastructure and costs. Rather than having disparate procurement teams working in silos to identify and approve costs, business, financial and IT leaders establish policies and best practices for usage that are programmatically enforced. The FinOps Foundation, an arm of the Linux Foundation, has been defining a set of FinOps best practices, but many organizations still lack the discipline required to implement them. One of the major reasons organizations lack this discipline is that many of them have been allowing application developers to provision cloud resources themselves. It’s not until the bill comes due at the end of the month that finance teams realize there is an issue when there is a sudden spike in costs.

    Rather than deploying a separate platform to manage FinOps, CloudBolt is making a case for integrating a framework for managing FinOps within the same platform IT teams use to manage those IT environments. That approach makes it possible to apply FinOps policies in a way that ensures best practices for controlling costs are implemented without creating yet another silo within an IT organization, said Campos.

    Running application workloads in the cloud is fundamentally different than running them in an on-premises IT environment where costs are largely fixed. Not many developers have much of an appreciation for the additional storage and cybersecurity expenses that are generated every time a new workload is added. As a result, many organizations lack visibility into the total cost of cloud computing until the monthly bill arrives. By then, it’s too late for IT teams to have any impact on the outcome.

    In the face of ongoing economic uncertainty, more organizations are clearly moving to reduce cloud computing costs more aggressively. In an ideal world, IT teams would be able to instantly see what impact any change to an IT environment will have on costs as part of any scenario planning exercise, said Campos.

    While most organizations would like to reduce their cloud costs, it’s just as important to ensure that the bills being incurred are predictable. Finance teams don’t appreciate surprises, no matter how important an application may be. IT leaders are now being held more accountable than ever to make sure cloud computing costs meet expectations from one month to the next. The challenge now is finding a way to inject controls in IT environments long after applications have already been deployed.