devopsy.kinsta.cloud

Category: News

  • Deloitte Aligns with Dynatrace for Observability

    Deloitte Aligns with Dynatrace for Observability

    Deloitte has expanded its cloud observability practice to include the Dynatrace Software Intelligence platform.

    Jay McDonald, managing director and co-chair for modern delivery at Deloitte, said the IT services provider will now provide traditional DevOps and observability consulting expertise along with a set of instances of the Dynatrace Software Intelligence Platform that it will manage on behalf of organizations.

    Deloitte opted for the Dynatrace platform because it employs a single agent for collecting metrics, logs and traces that are then analyzed by its Davis artificial intelligence (AI) engine to enable observability, said McDonald.

    While there is a growing appreciation for observability to enable DevOps teams to identify the root causes of IT issues before they become major problems, deploying an observability platform requires a lot of specialized expertise. Many organizations are opting to rely on third-party organizations such as Deloitte to manage that task within the context of a larger DevOps workflow, said McDonald.

    Managing those workflows has become especially challenging for many organizations to deploy and maintain as they move to build and deploy microservices-based applications, he added.

    Michael Allen, vice president of worldwide partners for Dynatrace, said there are now already more than 4,000 organizations using the Dynatrace Software Intelligence Platform, a number that will continue to increase as observability platforms are consumed as a service.

    It’s not clear at what rate DevOps teams are embracing observability. The concept has always been a core DevOps principle, but, for the most part, more mature DevOps teams have only been able to achieve what amounts to continuous monitoring of pre-defined metrics. Observability platforms promise to surface anomalies indicative of IT issues before they escalate; DevOps teams can then launch queries to better determine their root cause and potential severity.

    One of the benefits of the Davis AI engine is that machine learning algorithms surface the root cause of many of those issues without requiring DevOps teams to know exactly how to construct the right query, noted Allen.

    However, the biggest challenge many DevOps teams encounter is they lack the skills required to deploy and manage observability platforms. In fact, many of them are now relying on third parties to manage a wide range of DevOps platforms so they can concentrate their efforts on actual workflows. Hiring and retaining DevOps professionals also has become more challenging as the total number of applications being built and deployed expands beyond DevOps teams’ abilities to effectively manage.

    One way or another, the days when IT teams determined the root cause of an IT issue by process of elimination are finally coming to an end. DevOps teams are gaining more visibility into their application environments in ways that surface more meaningful actionable intelligence, regardless of who sets and manages the observability platform. The opportunity to employ that intelligence to improve overall application resiliency and drive a wide range of digital business transformation initiatives is well within DevOps teams’ reach.

  • JFrog Integrates DevOps Portfolio With Microsoft Teams

    JFrog Integrates DevOps Portfolio With Microsoft Teams

    JFrog this week announced it has integrated its DevOps portfolio with Microsoft Teams to enhance collaboration.

    Deep Datta, a senior product marketing manager for JFrog, said JFrog Artifactory repository and the JFrog Xray software composition analysis (SCA) tool have been integrated via a JFrog App for Microsoft Teams tool that is now available.

    The goal is to make it simpler for DevOps teams to collaborate with other members of an organization that has standardized on Microsoft Teams for collaboration, said Datta.

    In general, as more organizations are realizing how dependent their business is on software, individuals ranging from application owners to cybersecurity professionals are now looking to collaborate with DevOps teams, noted Datta. In fact, in many cases, business process workflows now need to align with DevOps workflows as businesses become more dependent on software, he added.

    While many DevOps teams already use a range of collaboration tools, many of those same teams also need to access Microsoft Teams to engage individuals outside of those teams, said Datta.

    The emerging challenge is the number of communication channels that DevOps teams now find themselves using. Each new communication channel added doesn’t necessarily supplant existing platforms; it’s not uncommon for DevOps teams to use Microsoft Teams alongside Slack as well as traditional email depending on the type of messaging and collaboration required. In some cases, for better or worse, DevOps teams find themselves required to juggle multiple collaboration platforms over the course of any application development project.

    In general, the relationship between DevOps teams and the rest of the business is evolving in the age of digital business transformation. The pace at which applications are delivered and updated now has a material impact on business goals. Organizations are finding they need to align everything from marketing and customer support to financial planning with software development. A delay in one software development project can have a cascading effect that impacts every aspect of the business. The sooner information is shared via a collaboration platform the easier it becomes for the rest of the business to adapt and respond.

    Naturally, not every DevOps team is excited about the level of transparency required. Many issues a software development team would previously have handled internally are now exposed to the agenda of the board of directors. Application delivery and update deadlines are influenced more heavily by revenue goals than the available developer expertise. The key to managing all those expectations is to communicate more frequently. However, all that communication can also take time away from building applications. It’s important to isolate development teams from distractions—like a constant barrage of messages shared with multiple lines of business and across multiple communication channels.

    Of course, the only thing worse than all those messages is a failure to communicate critical information in a timely fashion. The challenge is to find a way to filter out all the noise and get critical information to the right person at the right time.

  • Red Hat CEO: Out | Blind Users: Revolt | ARM: Google Joins Party

    Red Hat CEO: Out | Blind Users: Revolt | ARM: Google Joins Party

    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: Matt Hicks is the new Red Hat CEO, visual accessibility is in focus, and Google Cloud rolls out ARM instances. (more…)

  • Security Compass Makes Visualizing AppSec Threats Simpler

    Security Compass Makes Visualizing AppSec Threats Simpler

    Security Compass this week updated its threat modeling platform for developers to make it easier to surface application security issues.

    The latest version of SD Elements 2022 adds support for developer-centric threat modeling diagrams, reusable components, more advanced reporting capabilities and 114 more just-in-time training (JITT) modules. In addition, Security Compass has now integrated its platform with the Black Duck software composition analysis (SCA) tool.

    Drew Koelemay, director of product management for Security Compass, said the goal is to make it easier for application development and cybersecurity teams to collaborate using a platform that visualizes cybersecurity threats within a DevOps workflow.

    That approach to application security is critical because it becomes easier for developers to understand how changes to applications improve the overall cybersecurity posture of complex app environments where there are lots of dependencies, he said.

    Once that visualization is achieved it then becomes possible to create reports highlighting the most prevalent threats and weaknesses across that portfolio, Koelemay noted.

    In the wake of a series of high-profile application breaches, organizations of all sizes are looking to better secure their software supply chains by implementing DevSecOps best practices. The issue that immediately arises is the cultural divide between application development teams and cybersecurity professionals. The Security Compass platform surfaces developer-centric visualizations of security issues to help bridge the historic divide that exists between those teams, said Koelemay.

    For the most part, cybersecurity professionals view development teams’ lack of cybersecurity expertise to be the root cause of many of the issues they encounter. It’s not that a developer deliberately sets out to build and deploy vulnerable applications. By the time the application is reviewed—often just a few days before it’s supposed to be deployed—it’s often too late to do much about most of the vulnerabilities that are discovered. Cybersecurity professionals and application development teams need to meaningfully engage each other much earlier in the application development life cycle.

    The simple truth is developers are not likely to reach out first simply because they don’t know what cybersecurity issues to look for in an application environment. Most of the time they are rushing to meet an application delivery deadline, which makes them perceive cybersecurity as a hurdle to overcome rather than an automated process integrated within their workflow. Cybersecurity professionals, therefore, need to find a way to more constructively engage developers. The onus is on cybersecurity teams to insert themselves at the front end of the application development process rather than waiting at the backend for an inevitable issue to arise.

    One way or another, application security is going to improve. The only thing yet to be determined is how painful the process will be. Tools that enable DevOps teams to see for themselves what issues are being encountered should go a long way toward reducing both the level of pain being experienced and the amount of time required to resolve the cybersecurity issue at hand.

  • Scribe Security Unveils Pair of Tools to Secure Software Supply Chains

    Scribe Security Unveils Pair of Tools to Secure Software Supply Chains

    Scribe Security today unveiled a Scribe Integrity tool that scans software artifacts to make sure they comply with IT organizations’ security policies before they are integrated into an application.

    The Scribe Integrity tool authenticates open source and proprietary source code before it is uploaded into a build. It assumes that all artifacts are “guilty” until they can prove their innocence, said Rubi Arbel, CEO of Scribe Security. That approach makes it possible to ensure the integrity of the overall software supply chain is maintained in a way that doesn’t adversely impact the productivity of developers, he added.

    In addition, the company launched GitGat, an open source policy-as-code tool based on Open Policy Agent (OPA) agent software that enables DevOps teams to periodically run reports that surface insights into the security posture of code residing in GitHub repositories.

    Arbel said that, in time, GitGat’s reach will be extended to add support for additional continuous integration/continuous delivery (CI/CD) platforms.

    The first release of Scribe Integrity addresses Node.js code and the npm package manager with support for additional types of code planned.

    The Scribe Integrity tool also identifies all dependencies to enable DevOps teams to generate an accurate software bill of materials (SBOM) as each software artifact is included in the application, he noted. That’s critical because it enables developers, IT operations and cybersecurity teams to simultaneously see what artifacts, including containers, make up an application, noted Arbel. In the future, the company plans to make available a Scribe Hub that will make it easier to share insights into those software artifacts, he added.

    A series of high-profile security breaches clearly demonstrated cybercriminals’ skill at injecting malware into software artifacts and compromise any application that incorporates that artifact into an application. That malware can then be activated at some later date to potentially compromise any number of downstream applications.

    Those incidents resulted in a greater appreciation for DevSecOps best practices to maintain the integrity of software supply chains. The issue that DevOps teams are trying to address is how to build more secure applications without slowing down the rate at which those applications are built and deployed. As such, DevOps teams are adding tools to the application development process that make it easier for developers to scan code before it is included in an application and verify the integrity of any software component that becomes part of a DevOps workflow.

    It’s unknown how long it may be before the adoption of DevSecOps best practices has a meaningful impact on application security. However, waiting to focus on security until after an application has been deployed is way too late. Cybercriminals today can discover flaws and misconfigurations in applications in a matter of minutes. As more applications are deployed, developers can find themselves spending more of their time fixing vulnerabilities than they do writing new code. A new approach to building applications that are secure from the ground up is clearly required.

  • Styra Unfurls Cloud Service for Implementing Compliance-as-Code

    Styra Unfurls Cloud Service for Implementing Compliance-as-Code

    Styra, Inc. today launched an authorization service based on the Open Policy Agent (OPA) software that can be invoked via an application programming interface (API).

    Torin Sandall, vice president of open source for Styra, said the Styra Run cloud service will make it much simpler to embed enterprise-grade authorization capabilities within applications. Today, developers spend too much time building, maintaining and operating their own authorization platforms to manage permissions across multiple applications.

    In addition to enabling developers to access pre-built OPA logic, Sandall noted the service also offloads storage and global replication of end-user permissions data to a cloud service.

    The service itself currently runs on Amazon Web Services (AWS), but Styra plans to make the service available on other cloud platforms in the future, he added.

    OPA makes use of a general-purpose policy enforcement engine that developers can embed within applications using the Rego language. OPA is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) and is gaining traction among cloud-native application developers. OPA provides a means to enforce compliance-as-code across a wide range of microservices that now routinely access a wide range of distributed data.

    However, Styra Run should make OPA more accessible to a wider range of organizations, especially those that are looking to shift responsibility for security and compliance further left toward developers as part of a set of DevSecOps processes, noted Sandall. Developers that don’t have a lot of compliance expertise can now rely on a cloud service that enables them to focus more of their time and effort on writing code, he added.

    The arrival of Styra Run also comes at a time when more organizations are reviewing their software supply chain processes in the wake of a series of high-profile security breaches. It’s not clear to what degree compliance and cybersecurity teams have developed an appreciation for OPA, but as more organizations embrace compliance-as-code, the pressure on those teams should decrease as those applications are inherently more secure than legacy applications.

    There will, of course, be some developers that prefer to embed OPA into applications themselves, but a cloud service accessed via API will be the path of least resistance for most developers building software-as-a-service (SaaS) applications, said Sandall. The issue may simply be making developers aware that another low-latency option exists; one that doesn’t require them to deeply master the Rego programming language for the sole purpose of achieving compliance, he added.

    Regardless of approach, the general expectation going forward is that applications will more easily be able to meet a wide range of compliance mandates without requiring IT teams to deploy and maintain dedicated compliance infrastructure. As such, there may soon come a day when any application that doesn’t use some type of compliance-as-code framework will simply be rejected out of hand.

  • CodeLogic Toolkit Increases Visibility Into App Dependencies

    CodeLogic Toolkit Increases Visibility Into App Dependencies

    CodeLogic launched today a toolkit that enables developers to scan binaries, runtime application behavior and database connections and then leverage graph technology to identify connections and dependencies in real-time.

    Brian Pierce, CodeLogic CEO, said the goal is to make it simpler for developers to identify the relationship between application elements to increase overall productivity and simplify the addition of new members to an application development project.

    In general, most developers add code to applications without really having much visibility into how that code might impact other components. The toolkit created by CodeLogic is an extension of the company’s existing continuous software intelligence (CSI) platform that employs server software to store and process data collected via its agent software. The goal is to make it easier for developers to directly consume those insights via a toolkit they can access directly from within, for example, an integrated development environment (IDE), said Pierce.

    As applications become more complex in the age of microservices, it becomes more challenging to understand all the dependencies between application components. Developers require greater visibility into applications to better manage the break/fix process that inevitably occurs when new code is added to any environment. The CodeLogic CSI platform provides an automated impact score for methods, classes and the overall health of an application as code is developed to provide that visibility.

    That information also plays a critical role in enabling IT teams to understand the implications any newly discovered vulnerability might have on the application environment, added Pierce.

    Overall, the level of technical debt that organizations accumulate over time saps developer productivity, he noted. The more difficult it becomes to add code to an application environment the less likely it is that developers will enthusiastically make the effort, said Pierce. Before too long, the number of updates made to an application environment starts to decline, he noted.

    Developer productivity has become a major issue simply because the number of applications that organizations now want to build and deploy is exceeding the financial resources they have available to hire or contract developers. The more time developers spend studying how an application has been constructed the less time there is to write code and drive innovation. In fact, the more frustrating it becomes to add code the more likely it becomes developers will move on to a company with much less friction involved in building and deploying applications, said Pierce.

    There are many senior IT leaders that also need visibility into application environments before approving projects. Many IT teams discover that there are multiple projects or other teams writing duplicate code or replicating existing functions. Regardless of the reason, more developers are voting with their feet when they feel their time and effort is not fully appreciated.

  • GitGuardian Tightens Integration With GitHub to Secure Secrets

    GitGuardian Tightens Integration With GitHub to Secure Secrets

    GitGuardian has expanded its ability to secure code repositories by providing deeper integration with GitHub.

    Ziad Ghalleb, product marketing manager for GitGuardian, said the results of security scans are now provided in the context of pull requests alongside suggestions for remediating issues.

    The company also expanded developer onboarding options by adding an application programming interface (API) key provisioning mechanism integrated with its command line interface (CLI) in addition to making it easier to configure that CLI.

    Finally, GitGuardian extended support for role-based access controls (RBAC) to its platform so that team members can be assigned different permissions levels for incidents based on their role.

    GitGuardian makes it possible to scan source code to detect API keys, passwords, certificates, encryption keys and other sensitive data in a code repository in real-time. Developers building an application often make secrets easily accessible as plain text for the sake of convenience. However, when those applications are deployed in a production environment, developers often forget to delete these secrets. Cybercriminals know to scan for these secrets to make compromising an application environment easier.

    A recent GitGuardian report found a typical company with 400 developers would discover 1,050 unique hardcoded secrets when scanning its entire codebase. Each secret had 13 different occurrences, which meant the effort required to remediate those associated vulnerabilities would be considerable, the report noted.

    Secrets management is, of course, getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. GitGuardian makes it simpler to achieve that goal within the context of a set of DevSecOps best practices by integrating with GitHub with a single click, said Ghalleb.

    It’s still early days as far as adoption of DevSecOps best practices is concerned, but it’s clear more responsibility for application security is being shifted left toward developers. The challenge is many developers still lack the tools required to make sure applications are secure before they are deployed in production environments.

    Naturally, the earlier an application security issue is resolved the less costly it is to fix. The problem with secrets management is cybersecurity teams are usually a lot more focused on discovering vulnerabilities than looking for instances of poorly secured credentials. Once an application is deployed in a production environment, it may be months before anyone discovers there is an issue—if it’s discovered at all. In fact, the number of existing applications running in production environments that have secrets management issues could be staggering.

    One way or another, it’s only a matter of time before more of those issues are surfaced. In the meantime, DevOps teams can reduce the number of applications that might have this issue by making it easier to discover secrets within applications before they are deployed in production environments. After all, the only thing worse than a secret being discovered by a cybersecurity team is having one uncovered by cybercriminals that use it to wreak havoc.

  • This DevSecOps Thing Is Real After All

    This DevSecOps Thing Is Real After All

    Whether you made it to San Francisco, California last month for RSA Conference or not, you don’t want to miss Tuesday’s DevOps Connect: DevSecOps Virtual Summit.

    On Tuesday, July 12, 2022, we are presenting a virtual broadcast of the sessions from our recent DevOps Connect: DevSecOps event at RSA Conference in June 2022. All of the great sessions will be available as well as some bonus sessions that didn’t make it to RSAC.  

    For me, this event was extremely gratifying because it served as validation that I wasn’t crazy all those years ago. When I started DevOps.com in 2014, I did so because I thought it would be great for security—back then it felt as though I was a lone voice crying out in the wilderness! Now, here we are in 2022 and DevSecOps is real. It is accepted, it is sought-after and it is changing the way software is developed, deployed and managed.

    When I put on the first DevSecOps event at RSA Conference seven years ago, it was a bit controversial. The idea of bringing together the security community with the DevOps tribe was like what I imagine peace treaty negotiations between two warring parties would be. The security folks said no one else cared about security. The DevOps people, like many other IT pros, claimed the security folks were just people who said no to all their initiatives. The lack of trust ran deep. But we kept at it—and while the situation is far from perfect today, so much progress has been made.

    This year’s event featured our best speaker lineup yet. Jim Zemlin, executive director of The Linux Foundation, kicked off the event by talking about open source and security—software supply chain, SBOMs and security, oh my!  Continuing the open source and security trend, CNCF executive director Priyanka Sharma presented a great session discussing cloud-native and DevSecOps.

    And you won’t want to miss two of my favorite sessions. The first involves my friend John Willis asking, “What would Deming do?” in his session at 11:30 a.m. ET. Given the current state of world affairs and the software and security market, what would Edward Deming, the patron saint of DevOps, say and do? John is a bit of a Deming expert himself, so his insights are spot on, I think. And second, Carolyn Wong (who is a superstar) talks at 12:00 p.m. ET in her session about pentesting at scale, pentesting-as-a-service and DevSecOps.

    But wait—there’s more! Chenxi Wang has a powerful session, delivered off the cuff, about the current state of DevSecOps, software supply chain security, investing and more; that’s at 9:55 a.m. ET.

    We’ll also feature two amazing panels: One is made up of the authors of a recent book, Reinventing Cybersecurity. The other features folks from Intel, Mitre, NIST and the U.S. Senate talking about security compliance with an emphasis on software supply chain security and SBOMs (see a pattern here yet?).

    And that’s just the tip of the iceberg—there is even more from this year’s event that you don’t want to miss. So, head on over and register—it’s free. Many of the speakers will be online, live, during their presentations to answer questions, network and offer their guidance. There are also exhibits and sponsor booths and other fun stuff like a yoga class and a DJ spinning great tunes.

    This DevSecOps stuff is real and you will learn a lot from these sessions. We can’t wait to see you there!

    While you’re at it, check out our upcoming CloudNativeDay Virtual Summit August 10, 2022, which is shaping up to be a great event, as well!

  • BMC Adds Support for DORA Metrics to Mainframe Tools Portfolio

    BMC Adds Support for DORA Metrics to Mainframe Tools Portfolio

    BMC this week announced it has added support for DevOps Research and Assessment (DORA) metrics within its portfolio of DevOps tools for mainframe environments.

    John McKenny, senior vice president and general manager for intelligent Z optimization and transformation at BMC, said the latest edition of BMC Compuware zAdviser now includes a DORA KPI Dashboard that aligns with the widely-adopted framework for measuring DevOps efficiency defined by an arm of Google.

    The DORA metrics track deployment frequency, failure rate, lead time for changes and mean-time-to-recovery (MTTR). Tracking those metrics is crucial for IT teams that have mainframes because they need to make sure applications continue to be deployed on the platform versus being usurped by another platform that is perceived to provide a faster alternative for builds and deployment, noted McKenny.

    BMC also added support for automated webhook notifications to its BMC Compuware Abend-AID offering. That includes diagnostic and root cause analysis to resolve defects in test and production faster. In addition, BMC provides a connector to the machine-identity management platform created by Venafi. That integration promises to eliminate certificate-related outages that can derail an application development initiative.

    In general, DORA metrics are being used to identify areas where DevOps teams can improve. It is up to each organization to determine to what degree those metrics will be used to coach teams versus enforce productivity mandates. However, given the overall shortage of available DevOps talent, few organizations are employing metrics to force DevOps teams to improve. In fact, there is no universal set of DevOps goals that every organization is trying to achieve. Rather, most organizations are trying to determine what set of DevOps best practices makes the most sense to implement given their own goals and internal culture. In the case of the mainframe, most organizations start with a few projects before they begin to employ DevOps more widely, noted McKenny.

    The metrics defined by DORA framework are, of course, only a subset of the total metrics that DevOps teams should track. BMC, for example, makes it possible to track tools usage to provide DevOps teams with insights into what tools may no longer be relevant or required, noted McKenny.

    Mainframe environments also have a long history of using waterfall-based approaches to building and deploying applications that many of them will continue to use alongside DevOps practices, depending on the type of application being built and deployed. In other instances, distributed applications built using DevOps practices are being integrated with mainframe applications that now need to be updated using the same workflow. The mainframe is no longer a platform that is managed in complete isolation from distributed computing environments.

    The major challenge is that many organizations using mainframes often overestimate how difficult it is to adopt DevOps  best practices, McKenny said. Regardless of the platform, there is no doubt the overall rate at which all applications are being built and deployed will continue to increase. The mainframe is proving to be no exception to that rule.