devopsy.kinsta.cloud

Author: Mike Vizard

  • CircleCI Will Use AI to Increase Collective DevOps Intelligence

    CircleCI Will Use AI to Increase Collective DevOps Intelligence

    CircleCI has committed to adding additional collective intelligence capabilities to its continuous integration/continuous delivery (CI/CD) platform that will leverage machine learning and other forms of artificial intelligence (AI) to optimize application development and delivery.

    CircleCI CEO Jim Rose said that as the company’s namesake CI/CD platform continues to collect more telemetry data from multiple customers, it becomes feasible to create AI models that will optimize everything from application testing to reliability and performance.

    As part of that strategy, CircleCI has also added capabilities such as test splitting recommendations that employ machine learning algorithms to estimate the expected time savings of enabling parallelism on test jobs.

    In addition, CircleCI is creating a team of analysts and data scientists to develop additional AI capabilities based on the data collected via the cloud version of the company’s platform.

    The decision to invest more in developing AI capabilities follows the acquisition of Ponicode, a provider of a unit testing platform, earlier this year. That platform uses AI to augment application testers by providing capabilities such as syntax validation, on-hover hints and autocompletion capabilities to improve the accuracy of software developed using Visual Studio Code. The goal is to integrate that AI testing technology within the CircleCI platform to make it possible to apply algorithms to individual developers’ code as well as to code aggregated from multiple developers within a build as it is continuously updated across a DevOps workflow.

    The workflows make up a software supply chain that, in many regards, functions like any other type of supply chain, noted Rose. As such, there is plenty of opportunity to apply AI models to optimize those workflows in the same way AI is being applied to optimize other types of supply chains, he added.

    It’s still early days as far as applying AI to DevOps processes is concerned, but it’s clear there is a need to further automate a wide range of manual processes. It’s not likely that AI is going to replace the need for DevOps engineers any time soon, but it will reduce a lot of the toil that currently hinders productivity. The challenge, of course, is that it takes a lot of telemetry data to train an AI model, which typically can only be efficiently gathered and stored with a cloud platform. Less clear is whether AI capabilities might drive more organizations to shift away from legacy CI/CD platforms deployed in an on-premises IT environment where there might not be enough telemetry data available to effectively train an AI model.

    The one thing that is certain is there is now a race to apply AI to DevOps workflows. Organizations that have adopted DevOps typically are highly committed to automation, but the amount of AI applied to those workflows has been limited thus far. In the coming year, however, chances are good the amount of AI being applied to DevOps workflows will steadily increase, especially as many DevOps teams struggle to keep pace with complex application environments.

  • 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 as part of an effort 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:

    Indeed.com

    Gridiron IT
    McLean, Va.
    DevOps Engineer
    $195,292 to $205,031

    Dice.com

    Odyssey Information Services
    Remote
    Senior DevOps Engineer
    Up to $150,000

    ZipRecruiter

    K&L Wine Merchants
    San Francisco
    DevOps Engineer
    $125,000 to $150,000

    LinkedIn

    Compassion International
    Remote
    DevOps Specialist – Splunk
    $111,930 to $139,910

    SimplyHired

    Zoom Video Communications
    Virginia
    DevOps Engineer
    $97,920 to $181,170

  • Palo Alto Networks Buys Cider Security to Lock Down Pipelines

    Palo Alto Networks Buys Cider Security to Lock Down Pipelines

    Palo Alto Networks this week extended its efforts to secure application environments by agreeing to acquire Cider Security, a provider of a platform for securing continuous integration/continuous delivery (CI/CD) platforms, for approximately $195 million in cash.

    The acquisition of Cider Security, scheduled to close this quarter, will extend the reach of the company’s Prisma Cloud platform that was updated last year to include a set of tools for securing infrastructure-as-code (IaC) used to provision IT infrastructure. Palo Alto Networks previously acquired Bridgecrew, which had developed an open source Checkov policy-as-code tool. Last month, Palo Alto Networks added software composition analysis tools to Prisma Cloud, as well.

    Cider Security developed what it described as an operating system for application security. The solution creates a graph that enables DevOps teams to visualize the relationships between all elements that make up a software development environment, including code. It then makes it possible to apply a set of controls to remediate any vulnerabilities and attack paths that might be identified using any number of third-party scanning tools.

    Palo Alto Networks CEO Nikesh Arora told industry analysts the acquisition is an example of the company doubling down on securing software supply chains alongside its existing portfolio of platforms and services for securing production environments.

    It’s not yet clear who is in charge of DevOps platform security, but increasingly there will be some type of central security function that works with application development teams to lock down software supply chains, said Mike Rothman, general manager for Techstrong Research, an arm of the parent company of DevOps.com. “There’s going to be a central security group focused on securing the pipeline,” he said.

    As Palo Alto Networks continues to extend the reach of Prisma Cloud left, it continues to make a case for centralizing the management of cybersecurity through a portfolio of platforms that can be centrally managed via the cloud. It’s not clear how much organizations are centralizing management of security across their software supply chains and production environments, but Arora noted that interest in consolidating security vendors is high as organizations look to reduce the total cost of cybersecurity.

    In the meantime, organizations of all sizes are looking to employ DevSecOps best practices to better secure software supply chains in the wake of a series of recent high-profile breaches. In addition to scanning code for vulnerabilities, many of those organizations are starting to realize the tools and platforms used to build applications are also vulnerable to cyberattacks. The goal of those attacks is to insert malware that will manifest itself in any number of downstream applications that are eventually deployed in a production environment.

    It’s not yet apparent just how compromised those tools and platforms may be, but it’s clear software consumers are moving toward holding developers more accountable for vulnerabilities. The best-known example of those requirements is an executive order issued by the Biden administration that will require federal agencies to include software bills of materials (SBOMs) that list known vulnerabilities. Many enterprise IT organizations are expected to adopt similar requirements.

    One way or another, however, the tools and platforms that make up a software supply chain, along with the code they produce, are going to be subject to much greater scrutiny than ever before.

  • Atlassian Extends Jira’s Reach Into DevOps Workflows

    Atlassian Extends Jira’s Reach Into DevOps Workflows

    Atlassian today added a range of capabilities to its Jira project management application that make it easier to manage software development projects, including a toolchain page that simplifies tool discovery for any given project.

    In addition, Atlassian is including a Discover tab on that page that makes it possible to track activities and set priorities by providing more context around the goals for any given project.

    Atlassian said it also plans to add scope change insights later this month and, in the first quarter of 2023, auto-detection of stuck issues will be added to an existing ability to predict when application development projects will be completed.

    The company has also added a pull request activities feed to the Code tab in Jira to make it easier to compare and contrast issues, identify anomalies and discover opportunities to move work forward along with a Code insights view for tracking branch, commit, pull request and deploy activities.

    The Releases tab in Jira now surfaces feature flag status alongside development, build and deployment statuses. There’s also an ability to automatically generate release notes in the Confluence wiki application provided by Atlassian. Finally, in 2023, Atlassian is committing to making available a dark mode option for running Jira that some DevOps teams prefer.

    Suzie Prince, head of product for DevOps at Atlassian, said all these Jira updates are extensions of an Open DevOps initiative the company launched earlier this year that integrated Jira with a wide range of DevOps tools. The goal is to make it simpler for DevOps teams to track project progress without necessarily having to deploy, for example, a separate analytics application. As part of that effort, Atlassian also revealed Jira has been integrated with Compass, an extensible catalog launched earlier this year for tracking software components and is available in beta.

    In effect, Atlassian is making a case for Jira to become a software development project tracking hub by automatically pulling data from various other DevOps tools. Rather than requiring a project manager to send multiple requests for updates to individual developers and manually enter data, Jira’s integrations with various tools can both pull relevant data and apply analytics in a way that makes it simpler to identify issues that are adversely impacting deadlines.

    Those insights can then be shared more easily with both development teams and other stakeholders in the business that have a vested interest in making sure project deadlines are met. It can also make it simpler for application development teams to justify the need for additional resources.

    Project management is, of course, one of those thankless tasks that doesn’t always get the appreciation it deserves. However, as it becomes easier to automatically collect data about the status of any given project, the task itself should become less intrusive. Hopefully, as those tasks become more automated, the friction that often exists between application development teams and project managers will also subside.

  • Fiberplane Notebook Tool Fosters DevOps Collaboration

    Fiberplane Notebook Tool Fosters DevOps Collaboration

    Fiberplane today announced it is making available a public beta of a namesake real-time collaboration notebook specifically designed for DevOps teams that need to quickly debug IT infrastructure.

    Fiberplane CEO Micha Hernandez van Leuffen said in the wake of the COVID-19 pandemic, it’s clear that the structure of DevOps teams has permanently changed now that more members of those teams work remotely. The challenge is that the tools provided to DevOps teams to manage IT environments were not designed to foster the level of collaboration that is now required, he added.

    Dashboards that were designed in a different era need to be replaced with tools that make it simpler for DevOps teams to collaboratively debug infrastructure in real-time, noted Hernandez van Leuffen.

    The Fiberplane notebook achieves that goal by using the same operational transformation algorithm used in Google Docs to enable teams to easily collaborate around a document or spreadsheet. The core platform itself is built in Rust and WebAssembly (Wasm), which Hernandez van Leuffen said makes it simpler to integrate Fiberplane as a plug-in into an existing DevOps workflow. Inside a Fiberplane Notebook, DevOps teams can, for example, write and run PromQL queries and display Prometheus charts alongside other data presented via an integrated graph.

    Fiberplane Notebook’s initial integrations are for Grafana Loki, Elasticsearch and Prometheus monitoring tools. It also exposes both an application programming interface (API) and command line interface (CLI) to automate notebook creation based on specific external events, such as monitoring alerts.

    In effect, Fiberplane is taking the concept of notebooks used for collaboration by data science teams and applying it to DevOps workflows, said Hernandez van Leuffen. The goal is to improve DevOps teams’ productivity by reducing the amount of time it takes to resolve any issue, he added.

    As IT environments become more distributed in the age of the cloud and microservices, troubleshooting issues invariably spans the responsibilities of multiple members of an IT team. Fiberplane, in effect, makes it possible to spin up a virtual war room that enables the members of an IT organization to collaborate until the issue of the moment is resolved.

    The speed at which any IT issue is resolved has become a crucial metric. Given the complexity of IT environments, it’s inevitable that incidents will arise. Ideally, IT teams would discover those issues before they disrupt the business. However, in reality, the metrics organizations use to evaluate the effectiveness of a DevOps team are, unfairly or not, how quickly IT issues are resolved once they are discovered. The longer it takes for a distributed DevOps team to marshal its resources the more likely it becomes that team will be perceived as being inefficient—regardless of what level of application availability is actually achieved.

    Savvy DevOps teams, of course, have implemented a wide range of incident management best practices that create a level of muscle memory for responding to a wide range of issues. The trouble is there will always be unforeseen issues that arise. DevOps teams, as a result, need to find ways to quickly focus on an issue that, for one reason or another, were simply too unpredictable to anticipate; they need to expect the unexpected.

  • SAP Adds Low-Code Platform to Build Custom Apps Faster

    SAP Adds Low-Code Platform to Build Custom Apps Faster

    At the SAP TechEd 2022 conference, SAP SE today announced it has added a low-code platform, dubbed SAP Build, to its portfolio to make it simpler for organizations to build custom applications.

    Sebastian Schrötel, vice president and head of low-code/no-code solutions for SAP, said SAP Build is designed to make the company’s low-code tools more accessible to a wider range of developers, including so-called citizen developers that generally don’t have a lot of programming expertise.

    The goal is to make it possible to monitor, analyze and automate processes by leveraging more than 500 templates available within SAP Build. The goal is to make it possible to not only build applications faster but also deploy them via a single click, said Schrötel.

    The company’s approach to building custom applications separates its core applications from code developed by others by running pristine instances of SAP enterprise resource planning (ERP) applications in a separate cloud, known as the SAP digital core. A custom application is then deployed in a separate cloud and accesses SAP data via application programming interface (API). That approach enables SAP to update its ERP environment without worrying about breaking custom extensions.

    Of course, not every organization has transitioned to that model, so there are still plenty of instances of SAP software running in on-premises IT environments extended using code written in Java or the proprietary ABAP programming language. Over time, SAP is hoping that custom code will either be retired in favor of a process it has added to its ERP platform or by a more modern instance of that process running with a custom application deployed on a separate SAP cloud platform.

    SAP also has partnerships with providers of low-code platforms like Mendix and OutSystems that organizations can employ to build applications, but with the launch of SAP Build, the company is making a more concerted effort to encourage organizations to adopt the low-code platform it developed.

    While it’s not clear how eagerly low-code tools are embraced by citizen developers versus professional developers, the one thing that is certain is the pace of application development is accelerating. In many instances, professional developers are embracing low-code platforms as an alternative to procedural code to reduce expanding application development backlogs brought on by digital business transformation initiatives. In other instances, professional developers are employing low-code tools to collaborate more easily with end users as they build and deploy the applications that drive those processes.

    Regardless of the motivation, the impact this accelerated rate of application development will have on DevOps teams is profound. Not only do these applications have to be deployed in production environments, but DevOps teams must also secure and maintain a much larger application portfolio. As a result, the need to automate DevOps workflows will become more pronounced than it already is.

  • Critical Vulnerability Discovered in Open Source Backstage Platform

    Critical Vulnerability Discovered in Open Source Backstage Platform

    Oxeye today disclosed that it has discovered a critical vulnerability in the open source Backstage software used to build developer portals. Backstage was originally created by Spotify.

    A 1.5.1 update to the Backstage platform remediated a sandbox escape vulnerability that can occur via a third-party Scaffolder plug-in that could be used to conduct unauthenticated remote code execution (RCE).

    Oxeye CTO Ron Vider said Oxeye worked with Spotify to responsibly disclose the issue and enabled a patch to be created prior to the disclosure of the vulnerability, which Spotify gave a 9.8 out of 10 severity rating.

    Backstage is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF), but is already widely used by organizations such as American Airlines, Netflix, Splunk, Fidelity Investments, Epic Games and Palo Alto Networks, as well as by Spotify.

    The vulnerability is another example of a potential template-based attack through which run shell commands can be manipulated to inject malware into an application development environment.

    In general, separating the logic from the presentation layer as much as possible can greatly reduce exposure to the most dangerous template-based attacks.

    Vider said Oxyeye is focusing its vulnerability research on cloud-native platforms such as Backstage that are generally being used to build modern applications based on a microservices architecture. It’s not clear to what degree organizations have transitioned away from more monolithic approaches to building applications, but it’s clear that a much larger percentage of applications are now being constructed using microservices.

    Cybercriminals, of course, are targeting these platforms as part of a sustained effort to compromise software supply chains in the hope that the malware they inject will find its way into multiple downstream applications. Those attacks, in turn, are convincing more organizations to embrace DevSecOps best practices to better ensure the integrity of their software supply chains. The challenge is many of those attacks are being aimed at open source software projects that don’t always have enough resources to quickly develop a patch in the event a zero-day vulnerability is disclosed.

    While it’s impossible to know the extent to which cybercriminals are already exploiting vulnerabilities in DevOps platforms, the level of cybersecurity scrutiny being applied has dramatically increased in the wake of a series of high-profile breaches. The Biden administration has even gone so far as to issue an executive order requiring federal agencies to better secure their software supply chains. As a result, DevOps teams should expect there to be a lot more DevOps platform vulnerability disclosures in the months ahead, and that those vulnerabilities will require immediate patching.

    Like it or not, software supply chains are going to become more secure. The only thing left to be determined is the level of pain that will be experienced as more vulnerabilities are discovered in the DevOps platforms that were used to construct them.

  • Codenotary Automates SBOM Creation

    Codenotary Automates SBOM Creation

    Codenotary today launched a tool that enables an application to automatically generate a software bill of materials (SBOM) by adding a single line to its source code.

    Codenotary CEO Moshe Bar said TrueSBOM makes it possible to self-report the components used to construct applications to any organization that uses them for the first time. In contrast, existing SBOMs only provide a snapshot of the components of an application at the time it was initially created, he added.

    IT organizations are being asked to trust application providers that all the modules specified in the SBOM are the only components being used. Codenotary is making a case for an approach that enables the organization consuming that software to spin up an SBOM in real-time on demand.

    From a DevSecOps perspective, adding a single line of code to the application to enable TrueSBOM should also eliminate the need to create and maintain separate text files to generate an SBOM.

    Awareness of the need for SBOMs has skyrocketed since the Biden administration’s executive order made it clear that federal agencies would require them from any software provider starting next year. Many enterprise IT organizations are likely to follow suit as part of a larger effort to better secure software supply chains in the wake of a series of high-profile cybersecurity breaches.

    That approach also makes it a lot simpler for organizations to accurately pinpoint where components are actually running any time a new zero-day vulnerability is discovered, added Bar.

    Priced at $1,450 per application stack per year, there are also lower-cost instances of TrueSBOM available for applications based on either a serverless framework or using the portable WebAssembly (Wasm) format.

    Most internal DevOps teams already have a good handle on what software components are being employed with the applications they deploy, said Bar. The issue is that the organizations that use that software can’t easily verify what components are being employed, he added. That’s problematic because an organization may have decided to prohibit deployment of a specific software component because of a known vulnerability. Rather than trust a text file created by the provider of an application, TrueSBOM allows the user of an application to maintain control over their software environment, noted Bar.

    It’s not yet clear how most organizations will operationalize SBOMs now that more of them are being created. Ideally, organizations should be able to approve only software that has components that have been verified to be secure. Armed with those insights, over time, it should become simpler to start reducing security technical debt with more secure applications, added Bar.

    The challenge, of course, is that the Codenotary solution requires the addition of one line of code to an application. However, as SBOM mandates become more stringent, the number of application providers that are anxious to comply with rules for securing software supply chains should increase. The issue now is finding a way for both the developer and consumer of that software to streamline a verification process that, in its current form, is too cumbersome to effectively manage.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report to highlight career opportunities for DevOps professionals as part of an effort 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

    ApTask
    Remote
    DevOps Architect
    $160,000 to $200,000

    SimplyHired

    FluentStream
    Remote
    DevOps Engineer
    $150,000 to $200,000

    LinkedIn

    The College Board
    Remote
    Senior DevOps Engineer
    $144,000 to $150,000

    ZipRecuiter

    Ushur
    Santa Clara, CA.
    Senior DevOps Engineer
    $130,000 to $140,000

    Indeed

    Element 84, Inc.
    Remote
    Senior DevOps Engineer
    $119,000 to $140,000

  • Aqua Security Claims Compliance With Biden’s Executive Order

    Aqua Security Claims Compliance With Biden’s Executive Order

    Aqua Security this week claimed it is the first software supply chain security platform provider to meet the attestation requirements as defined by an executive order issued to federal agencies last year by the Biden administration.

    A supplementary memo issued by the Biden administration required federal agencies to collect compliance attestation letters for all software they use by September 14, 2023. Those attestation letters need to confirm that the software development environments they employ are secure, that sources of code are trusted and that code vulnerabilities have been remediated, provenance for data and code is being tracked using a software bill of materials (SBOM) and that these processes are being consistently maintained.

    Eilon Elhadad, senior director of supply chain security for Aqua Security, said Aqua Security was able to meet those requirements within 100 days of the issuance of that memo. The Aqua Security platform for securing software supply chains is based on a platform it gained with the acquisition late last year of Argon, a provider of a set of tools that provides an agentless approach to integrating with continuous integration/continuous delivery (CI/CD) platforms that maps the development environment. Armed with those insights, it then becomes possible to prioritize and automate the remediation of vulnerabilities based on security best practices and compliance rules, noted Elhadad.

    The Argon platform also includes code-tampering detection technology that performs validity checks to make sure the integrity of the build process has not been compromised.

    Naturally, there’s plenty of time for other security platform providers to comply with the requirements set forth in Biden’s executive order. However, software development teams are also in a race against time. In the wake of a series of high-profile breaches, it’s become apparent how vulnerable software supply chains really are. Cybercriminals have increased their efforts to compromise developer credentials so they can embed malware in software components and activate them downstream if future application incorporate that component, noted Elhadad.

    It’s not clear how closely enterprise IT organizations are tracking the efforts of the U.S. government to secure its software supply chain, but any entity that builds software used by any of those agencies will be impacted. Advocates of DevSecOps best practices within enterprise IT organizations will undoubtedly use the Biden administration’s requirements to define a minimum baseline for securing software supply chains.

    In the meantime, a new front has clearly been opened in the cybersecurity war. The more applications are targeted, the greater the impetus for shifting responsibility further left toward application development teams becomes. The challenge is not just scanning the code being written by developers, but also making sure the software build created by development teams has not been compromised by bad actors that have inserted themselves into the process, noted Elhadad.

    Given the magnitude of the effort required, it’s not likely that every software supply chain will be secured any time soon. However, the responsibility for securing those software supply chains is weighing more heavily on DevOps teams.