devopsy.kinsta.cloud

Category: News

  • Radware Embraces APIs to Improve AppSec Across Multiple Clouds

    Radware Embraces APIs to Improve AppSec Across Multiple Clouds

    Radware this week launched an application programming interface (API) approach to securing multiple clouds designed from the ground up to be an extension of a DevSecOps workflow.

    Eyal Arazi, a senior product marketing manager in Radware’s security group, said that Radware SecurePath makes it possible to invoke any of the company’s cloud security offerings via an API. That eliminates the need to depend on inline security platforms that require separate consoles to be managed.

    Instead, the out-of-path approach enabled by Radware makes it simpler to consolidate the management of security across multiple clouds, he said. The API approach allows application requests to go directly from the client to the application server and reduces complexity and latency, eliminates routing changes and increases overall availability, noted Arazi.

    DevOps teams can now access the entire Radware cloud security portfolio, including the Radware web application firewall (WAF), API protection tools and a service that thwarts distributed denial-of-service (DDoS) attacks via a consistent set of APIs, said Arazi. Radware will continue to make those offerings available to be deployed inline or out-of-path as IT teams see fit, he added.

    Every time an organization deploys workloads on another cloud platform, an already complex security challenge becomes more complicated. Today, most of the responsibility for securing those clouds lies with cybersecurity teams. However, as DevOps teams gain access to tools and platforms that make it more feasible for developers and DevOps teams to programmatically manage security, more of the responsibility for it is shifting further left.

    Part of the benefit of that approach is the elimination of the need to deploy and manage firewalls on virtual machines or the need to reroute traffic via content delivery networks (CDNs) to inspect traffic, noted Arazi. It also enables the Radware security offerings to piggyback on the certificates that are already being employed in cloud platforms, he added.

    In the longer term, the goal is to reduce—or outright eliminate—the vulnerabilities that now routinely make it into production applications. Many of the cloud security issues that organizations regularly face can be traced back to misconfiguration mistakes made by developers. It’s not that a developer deliberately sets out to build and deploy vulnerable applications. Rather, they simply lack the expertise required to make sure that, for example, ports are not left open. In the absence of that expertise, more tools must be embedded within DevOps workflows to better ensure application security. After all, it may be years before most developers attain any meaningful cybersecurity proficiency.

    In the meantime, closer collaboration between DevOps and cybersecurity professionals is required. There are simply not enough cybersecurity professionals available to participate in every phase of an application development project. DevOps teams need to be able to identify and remediate issues as early as possible. Otherwise, a cybersecurity issue that gets discovered at the last minute is likely to prevent a workload from being deployed in a production environment.

    In the absence of any additional effort, it’s really only a matter of time before cybercriminals become more adept at compromising cloud application environments.

  • Google Allies With GitHub to Secure Software Supply Chains

    Google Allies With GitHub to Secure Software Supply Chains

    Google today revealed it has been working with GitHub to create a forgery-proof method for signing source code as part of an ongoing effort to better secure software supply chains.

    Bob Callaway, technology lead for open source software supply chain security at Google, said a prototype of this method, written in the Go programming language, generates non-forgeable provenance using GitHub Actions workflows for isolation and code signing tools for authenticity provided by Sigstore. Projects that make use of GitHub runners to run jobs can now achieve the third level of security as defined by the supply chain levels for software artifacts (SLSA) framework to assure software artifacts are authentic and trustworthy, he said.

    The reusable workflow also protects against possible interference from maintainers who could otherwise try to define the workflow in a way that interferes with the builder. The only way to interact with a reusable workflow is through the input parameters it exposes to the calling workflow, which prevents maintainers from altering information via variables, steps, services and defaults.

    The goal is not only to ensure the provenance of individual software artifacts but also make it possible to identify which build system was employed to create that artifact, said Callaway. In addition to working with GitHub, Callaway added that Google expects to apply this method to securing other build systems that organizations used to construct applications.

    Overall, Callaway said, Google is also working toward embedding security functions with DevOps platforms to ensure the integrity of software supply chains, in addition to educating developers on how to build more secure software.

    To protect against the possibility of one job tampering with artifacts used by another job, Google’s method creates a trusted channel. Job outputs send hashes that are then used to verify the binary received via the untrusted artifact registry. The OpenID Connect (OIDC) protocol, which GitHub just opted to support, is then used to prove the identity of the workflow to an external service, such as Sigstore, by attaching a unique JSON web token (JWT) to each runner. The token contains verifiable information about workflow identity such as the caller repository, commit hash, trigger and the current workflow path and reference.

    That makes it possible for the workflow to prove its identity to the  Fulcio root certificate authority provided by Sigstore. Fulcio signs a short-lived certificate attesting to an ephemeral signing key generated in the runner. A record of that signing is kept in Sigstore’s transparency log Rekor. Users can then rely on the signing certificates to verify provenance in a way that is authenticated and non-forgeable. That approach means maintainers don’t need to manage or distribute cryptographic keys for signing, which until now have made it challenging to manage code signing at scale, Callaway noted.

    In the wake of a series of high-profile security breaches involving open source software, Google and others have significantly increased the resources being applied to securing both open source and proprietary software within the context of a set of DevSecOps best practices. It may be a while before the benefits of that effort are pervasively employed by developers, but it’s clear that substantial progress is being made involving everything from the tools developers use to the build systems managed by DevOps teams.

  • Survey Shows Increased Focus on Modernizing IT, Retiring Apps

    Survey Shows Increased Focus on Modernizing IT, Retiring Apps

    A survey of 140 enterprise architects and IT leaders published today suggested that, while moving applications to the cloud remains a priority, more attention is being paid to reducing technical debt by retiring applications.

    Conducted by LeanIX, a provider of a platform for managing enterprise architecture and managing value stream management (VSM), the survey found 40% of respondents identified reducing technical debt created by legacy applications and modernizing legacy systems as their top IT priorities. A full 96% said their company has at least one project planned for this year aimed at reducing technical debt with more than half (52%) noting that retiring IT applications is the primary means they will employ to reduce technical debt.

    Nearly 60% considered migrating applications to the cloud to be a high priority, as well. However, less than a quarter of respondents (24%) identified cloud initiatives as a top IT priority. The second most important cloud initiative, identified by 41% of respondents, is to increase the number of SaaS applications being employed.

    Regardless of the approach to the cloud, nearly three-quarters (73%) of respondents said enterprise architects should form a closer connection with software development teams, with an almost equal percentage agreeing on the importance of tracking the business impact of software development.

    However, only 16% of those surveyed considered the evolution and improvement of their security posture a top priority, even though more than two-thirds considered security initiatives—such as improving risk assessment capabilities and adopting more zero-trust IT offerings—as important or highly important.

    Dominik Rose, vice president of product management for LeanIX, said enterprise architects—or someone within IT who assumes responsibility for enterprise architecture—are trying to minimize disruptions to the business as IT environments continue to expand and evolve. The challenge they encounter is there is usually a divide between software development teams and the rest of the business. The size of that divide will vary by organization; in general, though, digital business transformation initiatives should help bridge the gap—assuming enterprise architects can establish and maintain close connections with software development teams, noted Rose.

    LeanIX is making a case for an enterprise architecture management (EAM) platform that provides visibility into IT environments. The company also makes a VSM offering available on top of that platform that provides visibility into software delivery processes. The number of organizations that have adopted VSM platforms remains relatively small, but as organizations depend more on software to drive digital processes, the need for senior business and IT leaders to have more visibility into software delivery schedules is expected to increase.

    In the meantime, it remains to be seen just how aligned DevOps teams are with the strategic goals of the business. The ability to build and deploy software faster does not automatically equate to gaining a deeper understanding of the needs of the business. In fact, there may come a day when software is built and deployed faster than most organizations can effectively absorb unless they have some equivalent of a VSM platform in place.

  • New Relic Adds SLO Tools to Observability Platform

    New Relic Adds SLO Tools to Observability Platform

    New Relic this week made a service level indicator (SLI) and service level objective (SLO) capability generally available within the New Relic One observability platform. The new capability makes it possible for DevOps teams to customize metrics, unified health reports and alerts.

    Alex Kroman, general manager and senior vice president for product engineering for New Relic, said the goal is to enable DevOps teams to more easily optimize services that span multiple applications and software components at a time when more organizations are relying on software to drive digital business transformation initiatives.

    IT teams have, of course, been tracking SLOs for decades. However, as application environments have become more distributed—thanks, in part, to the rise of microservices—achieving and maintaining SLOs has become more challenging. DevOps teams often lack an understanding of which metrics are most relevant to the business and even when they do, they have historically relied on manual processes and ad hoc tooling, noted Kroman.

    In contrast, New Relic is providing those capabilities in a way that makes it simpler to manage service levels at no additional cost, he added. DevOps teams can, for example, create SLIs in one click to automatically establish a baseline of desired performance and reliability. The platform also provides recommendations based on historical data to both establish benchmarks and customize and configure SLIs and SLOs.

    Those capabilities make it simpler to set service boundaries and track reliability across teams based on benchmarks, tags and reports that include bespoke views for both service owners and business leaders. In effect, via an application programming interface (API) exposed by New Relic, it becomes possible to employ dashboards to gain visibility across an entire business process, said Korman.

    It’s still early days as far as the modernization of SLOs is concerned, but it’s clear that, over time, they will be managed as code along with everything else in a DevOps workflow. The more organizations become dependent on applications to drive digital business initiatives, the more critical it will become for DevOps teams to track SLOs. The decision that must be made is the degree to which it makes sense to manually implement some form of SLO-as-code versus relying on an observability platform that can be accessed as a cloud service.

    Observability, of course, has always been a core tenet of DevOps. Few organizations are able to really achieve it, however, because most IT teams have been monitoring little more than a pre-defined set of metrics. Modern observability platforms make it easier for site reliability engineers (SREs) to launch queries against aggregated instances of metrics, logs and distributed traces to ascertain the root cause of an issue. The issue then becomes how to correlate the results of those queries against the service levels that businesses expect from a set of applications that might be driving, for example, an order-to-cash process. After all, knowing what occurred within an IT environment doesn’t always easily translate into a report that the average business executive can easily comprehend.

  • Facebook Bans Innocent Users | Azure and ARM/Ampere | ‘Great Resignation’—No End in Sight

    Facebook Bans Innocent Users | Azure and ARM/Ampere | ‘Great Resignation’—No End in Sight

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: No remedy for banned Facebook users, new ARM-based VMs on Microsoft Azure, and The Great Resignation will still be a Thing for the foreseeable. (more…)

  • Researchers Find Privilege Escalation Vulnerability in GitHub Repos

    Researchers Find Privilege Escalation Vulnerability in GitHub Repos

    Legit Security today revealed that it discovered a privilege escalation vulnerability in GitHub repositories that has since been remediated.

    Liav Caspi, Legit Security CTO, said the company worked with GitHub to remediate the issue prior to disclosure. Legit Security researchers reported they found hundreds of GitHub instances rated with over 1,000 stars each that could be subject to the vulnerability.

    Caspi said the company also reached out directly to most of those affected sites, including an instance of GitHub that is used to develop the open source Nginx web server that is employed across hundreds of millions of websites.

    Cybercriminals could exploit a vulnerable build script to modify code or built artifacts that would result in software being shipped with code controlled by some other entity. The vulnerability could also enable access to sensitive secrets, such as keys, that are used to access cloud services or simply create a malicious pull request.

    Legit Security researchers employed a set of risk assessment tools that are part of a larger software-as-a-service (SaaS) platform that enables them to apply security policies across their entire software development life cycle. Earlier this year, the company made available a free Rapid Risk Assessment tool to provide organizations with more insights into their software supply chains. Security research findings, along with other security best practices, are embedded within the policies that can be enforced via the Legit Security platform.

    In the wake of a series of high-profile breaches, there is now more focus on the security of software supply chains than ever. Gartner estimated that 45% of organizations worldwide will have experienced attacks on their software supply chains by 2025, a threefold increase from 2021.

    Despite those concerns, however, the rate at which new applications are being deployed and updated doesn’t appear to be slowing. Organizations are too dependent on software to encourage customers to slow down the development and deployment rate of applications. It will, however, take years for organizations to properly train developers to correctly employ security tools within their application development processes, otherwise known as DevSecOps best practices, to reduce the number of vulnerabilities that now routinely manifest themselves in production environments. The only practical alternative is to embed more tools that automatically discover vulnerabilities in code during the application development process.

    Regardless of the DevSecOps approach, the ultimate goal remains to build more secure applications faster. That can only be achieved if there are more guardrails in place that prevent developers from inadvertently introducing vulnerabilities into an application. The more frequently applications are updated, the more likely it is that a vulnerability will be introduced. Each time those vulnerabilities are discovered after an application is deployed in a production environment, the more expensive they are to remediate. As the volume of vulnerabilities increases, it’s also only a matter of time before the sheer number of security issues that need to be addressed overwhelms both developers and security operations teams alike.

    Application security, of course, has not always received the attention it deserves, but demands for increased application security can no longer be ignored.

  • Fixing Spring4Shell Starts With Software Supply Chain Management

    Fixing Spring4Shell Starts With Software Supply Chain Management

    Spring4Shell is the latest call to action for radically improved software supply chain integrity. While Spring4Shell investigations continue, one conclusion is indisputable: We must holistically rethink the way we continuously inventory and manage the complex landscape of interrelated software and its sources.

    Whether or not Spring4Shell surpasses the breadth of impact of Log4j, there’s still massive potential for severe consequences to software and API security across the open source infrastructure, frameworks and application software stacks.

    That’s because, as we saw with Log4j, this attack could impact most enterprise Java applications globally. It seems the root cause is a vulnerability in the widely used, free, community-developed, open source programming framework Spring Core.

    The Spring framework is the foundation for most enterprise Java applications—as many as 74%, according to some data. Specifically, Spring serves as the foundation for enterprise Java apps so that teams can focus on application-level business logic without being locked into specific deployment environments.

    Spring Core’s ubiquity introduces significant potential for widespread impact due to its use across enterprise software, cloud services, third-party software and service products as well as internally managed software. This is another call-to-action to improve the way we approach software supply chain security and supply chain management. Thankfully, there’s already a place to start.

    Every infrastructure and software team can begin addressing this vulnerability by leveraging resources from The Linux Foundation’s Software Bill Of Materials (SBOM) project. The 2021 initiative included an SBOM readiness survey, a Generating Software Bill Of Materials training course and an SBOM generator tool based on the SPDX standard (ISO/IEC 5962:2021).

    The Linux Foundation’s SBOM contributions provided all of us a head start to begin addressing issues with software supply chain management. With widespread adoption, SBOM equips software projects and users to assess and address Spring4Shell as well as any other as-yet-unknown vulnerabilities and prepare us for what is undoubtedly a season of high-impact infrastructure software vulnerabilities.

    For more Spring4Shell resources, please visit: https://www.contrastsecurity.com/security-influencers/new-spring4shell-vulnerability-confirmed-what-it-is-and-how-to-be-prepared

  • GitLab Updates CI/CD Platform to Improve Dev Productivity

    GitLab Updates CI/CD Platform to Improve Dev Productivity

    GitLab has made available a 14.9 update to its namesake continuous integration/continuous delivery (CI/CD) platform that adds epic-linking, integrated security training, rule mode for scanning result policies and a revamped design, among other capabilities. The updated environment makes it easier to discover the state of the application development projects, GitLab said.

    Cindy Blake, director of product marketing at GitLab, said these updates are part of an ongoing effort to embed technologies within the CI/CD platform that will make applications both more secure and compliant with various mandates before they are deployed in a production environment.

    For example, DevOps teams can now take advantage of a user interface through which they can use a rule mode to design and edit policies without the need to access YAML files directly.

    GitLab has also partnered with Kontra and Secure Code Warrior to provide content that will drive security training functionality. This content can be accessed via the GitLab platform whenever a vulnerability is discovered.

    The overall goal is to make it simpler for organizations to shift left because expecting every developer to become a security expert is not especially realistic, noted Blake. The ability to automate many of the security tasks that developers face is a way of showing empathy for the daunting challenges they face.

    In general, as application development becomes more complex, GitLab is moving toward making its CI/CD platform more accessible to a wider range of organizations, including those that might only be starting to embrace DevOps best practices. The epic-linking capability, for example, makes it easier to identify “related”, “blocking,” or “blocked” relationships to better track and manage epic dependencies across GitLab groups.

    The two biggest challenges organizations face today are securing their software supply chains and improving the overall productivity of the developers. In most cases, those two goals are tightly coupled; every minute a developer spends on security is one less minute they spend writing code. In fact, many organizations are finding that, in addition to salary and benefits, many developers are using the level of friction they will encounter when building and deploying applications as a guide to decide which organizations they want to work for. As a result, many organizations are now looking to modernize their application development and deployment environments with an eye toward attracting the best developer talent.

    At the same time, of course, organizations are looking to improve the productivity of the developers they do have. In the age of digital business transformation, there are many more application development initiatives being launched. The challenge organizations face is that hiring and retaining developers remains a major challenge.

    It’s not clear how eager organizations are to replace their existing CI/CD platforms. However, the pressure to improve the overall developer experience is mounting at a time when organizations are increasingly dependent on software. Arguably, going forward, the ability of any organization to compete will be dependent on the productivity of application development teams. Platforms and tools that get in the way of enabling organizations to build and deploy more secure software faster will be discarded.

  • Lapsus$ Shames Okta/Sitel | Bitcoin Nukes Climate | EU DMA E2EE FAIL

    Lapsus$ Shames Okta/Sitel | Bitcoin Nukes Climate | EU DMA E2EE FAIL

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Okta and Sitel under fire over Lapsus$ hack, Greenpeace and others call for bitcoin change, and Europe still hates encryption. (more…)

  • GitLab Allies With Rezilion to Add Workload Analysis Tool

    GitLab Allies With Rezilion to Add Workload Analysis Tool

    Rezilion has integrated its workload analysis tool with the continuous integration (CI) framework provided by GitLab. The move is part of an effort to make it simpler for developers to discover issues such as vulnerabilities before they upload code into a repository.

    Sam White, a senior product manager for GitLab, said this integration will provide developers with an instant feedback loop that will enable them to address a wide range of issues before their code is ever reviewed. Rather than experiencing the shame of, for example, missing a vulnerability, the Rezilion platform enables developers to quickly write code while relying on a code analytics tool to surface common mistakes that they can remediate as they see fit, he added.

    Rezilion CEO Liran Tancman added that the proprietary workload composition analysis engine, dubbed Unison, on which the Rezilion platform is based makes it feasible to shift more responsibility for application security further left without requiring developers to become cybersecurity experts.

    Unison automatically creates a model of all the applications that include the underlying infrastructure and runtime environments. It reverse-engineers and maps that environment in memory to dynamically track the inventory, provenance, runtime execution, exposure and interdependencies between each piece of code and can generate a software bill of materials (SBOM).

    The code that is most in need of immediate attention is also surfaced directly with the GitLab user interface, said Tancman. That capability can reduce remediation time of the vulnerability backlog an organization might be working through by as much as 70% over time, he added. Rezilion enables organizations to achieve that goal because non-exploitable vulnerabilities are marked as “false positives” that shouldn’t hold back a release.

    Tancman said that without this level of automation it would be extremely challenging for an organization to implement a set of DevSecOps best practices. It might take developers years to attain the level of cybersecurity training that would be required in the absence of the automation enabled by the Unison engine, he noted.

    Historically, the relationship between application developers and cybersecurity teams has been tense. Cybersecurity teams tend to put off code review until it’s about to be deployed in a production environment. It’s not uncommon for an application to be pulled at the last minute because of a vulnerability discovered by a cybersecurity team. In some instances, that vulnerability is a legitimate concern but in others, it turns out to be a false positive because the flagged piece of code isn’t actually included in the application.

    By providing developers with a workload composition analysis tool within the context of a CI framework, GitLab is trying to reduce the level of friction that the process tends to create between developers and cybersecurity teams.

    It may be some time before most organizations fully master DevSecOps, but it’s clear that merely telling developers they will be held accountable for application security without providing the appropriate tools isn’t going to make applications any more secure.