devopsy.kinsta.cloud

Category: Features

  • Zenhub Brings Issues Management to Project Management Platform

    Zenhub Brings Issues Management to Project Management Platform

    Zenhub today announced it is adding an issue management module that makes it simpler for stakeholders to collaborate with developers on application development projects without having to log into a GitHub repository.

    Fresh from raising an additional $10 million in capital, Zenhub co-founder Aaron Upright said Zenhub Issues is a plug-in for a project management application the company developed for GitHub environments to better streamline software development life cycles. The issue is that many application stakeholders, such as marketers, are not especially pre-disposed to logging into a repository for managing software components, he said.

    Zenhub Issues provides an alternative means for collaborating with developers that doesn’t require stakeholders to log into GitHub, he said. In addition, organizations no longer need to acquire additional GitHub licenses for those users, noted Upright. Many of those end users wind up with read-and-write access to software components, which creates unnecessary cybersecurity risks should their credentials be compromised, he noted.

    In some cases, organizations will also be able to eliminate the need for the project management applications many of those stakeholders have adopted because they can track issues via Zenhub Issues, he added.

    Many organizations’ entire business strategies now revolve around accelerating the rate at which software development projects can be completed. Many elements of those projects, however, can’t go forward until a specific component upon which it depends is completed, so project management has become a critical function. Investors are holding business leaders more accountable for software delivery timetables that have direct implications on revenue generation, so that pressure naturally falls on DevOps teams.

    It’s not surprising that there aren’t a wider range of end users of project management applications as various stakeholders seek to keep closer tabs on how updates to schedule impact their planning cycle. Everyone from the sales team to the board of directors now wants more visibility into the rate at which software development projects are being completed. The challenge DevOps teams face is that software development is an inexact science. Application development projects can just as easily fall behind schedule as they can leap ahead depending on how well code is written.

    Regardless of how application development projects are managed, the relationship between DevOps teams and the rest of the organization has fundamentally changed. Unfortunately, expectations are not always realistically aligned with available development resources. A project management application that is widely employed across an organization should make that apparent to all interested stakeholders. In theory, at least, that should result in either the hiring of additional developers or a reassessment of the business strategy.

    One way or another, project management applications designed for managing software development projects now play a pivotal role in business planning. The challenge is finding a way to populate those applications with the data needed without requiring developers to help enter data that can already be easily pulled from the DevOps tools and platforms. Otherwise, instead of being viewed as a benefit, the entire project management process becomes one more tedious task that development teams are not going to prioritize over writing code.

  • IT Teams Need to Do More With Increased Budgets

    IT Teams Need to Do More With Increased Budgets

    A survey of 600 C-suite and IT decision-makers published today found the majority of organizations are trying to make increased IT budgets stretch even further as costs rise and the number of workloads deployed continues to increase steadily.

    Conducted by SoftwareOne Holding AG, a provider of software and IT services, the survey found 93% of respondents expected IT budgets to increase, with 83% planning to invest more in application modernization. However, 83% also noted they are under pressure to stretch budgets even further as part of an effort to increase agility (46%), improve customer experience (45%) and improve security to support remote workforces (45%). A full 92% said they would be increasing investments in security.

    The core issue that IT leaders are wrestling with appears to stem from increased cloud costs. The survey found the primary causes of those increased costs are inflation-related price hikes passed along by cloud service providers (41%), workloads exceeding planned capacity (40%), transformation initiatives that are cloud-dependent (40%), fewer cloud discounts (37%), lack of visibility into and management of cloud costs (34%), overprovisioning (34%), repercussions from previous lift and shift efforts (34%) and shadow IT (30%).

    Craig Thomson, senior vice president of cloud and application services at SoftwareOne, said that technical debt is having a significant downstream impact across organizations. For example, the survey found 72% of respondents reported that digital transformation initiatives are falling behind, with 38% noting the accumulation of this debt stems from rushed cloud migrations throughout the pandemic. Just under a third (31%) failed to optimize workloads before commencing the migration. More than a third (38%) admitted their organization miscalculated the cloud budget.

    Progress is being made, however, with 45% of respondents reporting they have improved transparency and control of cloud costs. A full 80% planned to increase their investment in financial operations (FinOps) to achieve this, and 39% said they would use cloud-native tools to reduce licensing costs.

    Those efforts suggested IT leaders are being very deliberate in their approaches to reining in costs while at the same time embracing best practices, said Thomson. IT leaders have finally started to realize the cloud is not so much a destination for workloads as much as it is an operating model, he added.

    The challenge is that cloud computing environments are becoming more complex to manage as organizations deploy cloud-native applications on Kubernetes clusters and serverless computing frameworks deployed alongside legacy monolithic applications that were lifted and shifted to the cloud. Organizations will need to invest more in automation to make up for an IT talent gap that prevents organizations from accelerating the rate at which they can build and deploy cloud applications, noted Thomson.

    On the plus side, it appears organizations are willing to allocate budgets to achieve their IT goals. The issue is that, as more organizations become more dependent on software, they are asking IT teams to do even more with the resources at hand. The degree to which that can be achieved, of course, is almost wholly dependent on how much of the technical debt that already exists in the cloud can be retired.

  • Tips For Securing CI/CD Pipelines

    Tips For Securing CI/CD Pipelines

    Most development teams want to increase the pace of their software delivery. As such, continuous integration and delivery (CI/CD) has grown in importance, helping push code from build to production as seamlessly as possible. CI/CD pipelines often loop in many elements and may comprise a diverse stack of tools, automations and various languages. But because of this, the attack surface can be large. And as gaps in the CI/CD toolchain emerge, so do security concerns.

    In recent years, we’ve seen several high-profile cases where CI/CD environments were compromised. For example, take the Circle CI breach, in which a bad actor accessed Circle CI production systems. Others include the compromise of the SolarWinds build system and the Codecov breach. CI/CD security issues are alarming because so much control and automation are given to a pipeline. Unauthorized CI/CD access could be leveraged to publish malicious code or steal sensitive information.

    I recently met with Daniel Krivelevich, co-founder and CTO of Cider Security (acquired by Palo Alto Networks), to better understand the risks facing modern CI/CD. Krivelevich is a seasoned CI/CD security expert and co-author of the Top 10 CI/CD Security Risks framework, which OWASP adopted in late 2022. According to Krivelevich, there is a general lack of knowledge and visibility into these risks. “The CI/CD ecosystem as a whole is full of holes and opportunities for attackers,” he said.

    Below, we’ll review some of the risks that CI/CD pipelines face and offer general ways to mitigate some of these concerns. Hopefully, with greater security awareness around CI/CD threats, both tooling providers and users can begin to diffuse the potential of attacks against their systems.

    The Top Concerns Facing CI/CD Security

    The OWASP Top 10 CI/CD Security Risks framework covers the most impactful risks within modern engineering systems and gaps in CI/CD. It was informed by analyzing many attacks in recent years and was compiled with insights from numerous experts. Krivelevich hopes the framework will spark discussions around the mindset defenders should have when they’re looking to protect the modern engineering ecosystem. The top 10 risks are as follows:

    • CICD-SEC-1: Insufficient Flow Control Mechanisms
    • CICD-SEC-2: Inadequate Identity and Access Management
    • CICD-SEC-3: Dependency Chain Abuse
    • CICD-SEC-4: Poisoned Pipeline Execution (PPE)
    • CICD-SEC-5: Insufficient Pipeline-Based Access Controls (PBAC)
    • CICD-SEC-6: Insufficient Credential Hygiene
    • CICD-SEC-7: Insecure System Configuration
    • CICD-SEC-8: Ungoverned Usage of Third-Party Services
    • CICD-SEC-9: Improper Artifact Integrity Validation
    • CICD-SEC-10: Insufficient Logging and Visibility

    Before an organization can dissect these individual risks, however, they must overcome an even bigger problem—a critical lack of understanding regarding the CI/CD ecosystem and the many elements under the hood. Since CI/CD is not traditionally viewed as a security risk, this can result in insecure default configurations, insecure processes and systems not adopting a secure-by-design approach.

    “There’s a big gap between the level of understanding and opportunities attackers have and the knowledge defenders have over what attackers can do,” said Krivelevich. “Organizations traditionally have not been proactive enough in understanding this, unlike other elements that are more traditionally recognized as part of the attack surface. The main gap is a mindset shift.”

    Tips to Secure CI/CD

    So, knowing the above risks, what are some best practices to secure CI/CD pipelines? Krivelevich shared some tips to keep in mind.

    Bring CI/CD under the security umbrella. First, realize that CI/CD should be scrutinized. This will require an awakening in the community and more proactive effort than before. Krivelevich encouraged development teams to place it on their roadmaps and think about it.

    Map the attack surface. Before implementing security measures, you need to know what you’re protecting. Therefore, it’s a good idea to map your CI/CD environment and produce an inventory of assets. Cataloging the total surface area of dependencies and integrations is necessary to understand risks and helps mitigate CICD-SEC-10: Insufficient Logging and Visibility.

    Keep this updated regularly. Since the cadence of change is fast, teams will want constant visibility into their ecosystem and what’s under the hood. This may even lead to shadow IT, as per CICD-SEC-8: Ungoverned Usage of Third-Party Services. Therefore, Krivelevich recommended keeping a regularly updated inventory. This means continually mapping control systems, container registry artifacts, plugins and all other assets used as part of CI/CD.

    Protect the software supply chain. Many building blocks make up the modern software delivery process. But, some dependencies may be abused or contain malicious code, as per risk CICD-SEC-3: Dependency Chain Abuse. Dependencies within the CI/CD process may be prone to a host of open source vulnerabilities.

    Safeguard CI/CD credentials. CI/CD tools “possess secrets to most sensitive crown jewels in an organization,” Krivelevich explained. Therefore, access tokens and secrets related to CI/CD tools should be protected to avoid costly credential leaks. A zero-trust approach to CI/CD could help avoid CICD-SEC-2: Inadequate Identity and Access Management.

    By creating a virtual heat map of areas to address, organizations will be more informed and better equipped to assess risk. And according to Krivelevich, by implementing these best practices, defenders have a lot of power to raise security expectations in the CI/CD space. “When defenders and users become more diligent about security, the requirements from vendors will increase.”

    CI/CD is the Beating Heart, Don’t Let it Break

    “The engineering ecosystem and pipelines themselves are the beating heart of engineering,” said Krivelevich. And as this system becomes a larger part of what makes a business tick, it will be more heavily relied upon for mission-critical tasks and retaining agility.

    Yet, many building blocks comprise the contemporary software delivery process, and CI/CD pipelines can be a risky area due to the number of systems they touch. Further complicating things is the fact that the delivery ecosystem wasn’t traditionally viewed in security terms. This combination of many opportunities and limited security oversight makes CI/CD lucrative for attackers.

    Rectifying the top 10 risks is a relatively easy gap to address, said Krivelevich—what’s not so easy is the mindset shift required to take CI/CD security seriously. Organizations that invested deeply into microservices and rapid engineering processes will most likely be more susceptible to attacks, he added, since they typically use a diverse array of tools and a complex, integrated delivery process.

  • Linux Tweak Brings Big Speedup ¦ DCs in SPAAACE (Redux) ¦ Atlassian Fires 500

    Linux Tweak Brings Big Speedup ¦ DCs in SPAAACE (Redux) ¦ Atlassian Fires 500

    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: Intel optimizes Linux multithreaded networking, data centers in space (again), and more DevOps toolmaker layoffs. (more…)

  • Survey: More Cybersecurity Pros Embedded in DevOps Teams

    Survey: More Cybersecurity Pros Embedded in DevOps Teams

    A survey of 2,500 C-level executives published today by Palo Alto Networks found 81% of organizations have embedded cybersecurity professionals within their DevOps teams.

    Despite the presence of those cybersecurity professionals, however, the survey also suggested there is much work to do in terms of optimizing DevSecOps workflows. A full 90% of organizations cannot detect, contain and resolve cybersecurity threats within an hour, the survey found.

    Bob West, chief security officer for Palo Alto Networks, said most of the challenges associated with DevSecOps are directly related to persistent cloud security issues. More than three-quarters of organizations (78%) said they had distributed responsibility for cloud security, but almost half (47%) said a majority of their workforce still does not understand their security responsibilities.

    In many cases, developers with little to no cybersecurity expertise are responsible for provisioning cloud infrastructure. As a result, misconfigurations that create security issues are commonplace, noted West. That’s especially problematic because three-quarters of organizations (75%) are deploying new or updated code to production weekly, with almost 40% committing new code daily, the survey found. Given that developers far outnumber cybersecurity professionals in most organizations, it remains challenging to ensure application code is secure, noted West.

    In addition to improving the overall state of cloud security, organizations need to focus on fundamentals such as training developers to be more mindful of cybersecurity issues, he added. Most developers never had any formal cybersecurity training, so it’s up to organizations to make sure that particular skills gap is closed, he noted. In addition, organizations need to make sure they have a robust set of patch management processes in place alongside a capability to manage permissions and entitlements, added West.

    Overall, the survey found organizations are using more than 30 security tools, on average, including six to 10 dedicated to cloud security. More than three-quarters of respondents (76%) said relying on multiple security tools created blind spots that affected their ability to prioritize risk and prevent threats. A full 80% said they would benefit from a centralized security solution that sits across all of their cloud accounts and services.

    One way or another, a rising tide of regulations focused on improving the security of software supply chains will force organizations to improve cloud security, said West. The survey showed there is a strong commitment in terms of making cybersecurity professionals an integral part of a DevOps workflow. The issue is that there are still a raft of training and process issues that need to be addressed at a time when cybercriminals are becoming increasingly adept at compromising applications both as they are developed and after they are deployed.

    Of course, training and modifying processes take time. DevSecOps is as much about changing culture as it is about acquiring new tools. DevOps teams are still highly committed to building and deploying applications as quickly as possible. The challenge is finding a way to insert a set of cybersecurity gates within those workflows without slowing down the pace at which applications are developed.

  • AWS Delivers on Latest Graviton3 Price/Performance Promise

    AWS Delivers on Latest Graviton3 Price/Performance Promise

    Amazon Web Services (AWS) has expanded the number of virtual machines based on the latest generation of its Graviton processors to include instances that support DDR-5 memory.

    The latest Amazon EC2 instance types, dubbed M7g and R7g, that are now generally available are based on the AWS Graviton3 processors developed using an architecture created by Arm. Previously, these instances were only available as part of a technology preview program.

    Rahul Kulkarni, director of product management at AWS, said these latest offerings take advantage of DDR-5 memory to provide 25% better performance than the previous sixth generation of Graviton instances. DDR5 memory increases the amount of bandwidth available by 50%, he noted.

    Graviton processors now provide the lowest-priced instance of virtual machines in addition to the best performance and overall price/performance across the AWS portfolio, Kulkarni added.

    AWS is making a case for employing its AWS Graviton processors for general-purpose workloads as more IT teams are being tasked with reducing costs as the overall number of applications being deployed in the cloud continues to increase. In fact, all of the top Fortune 50 companies have already deployed workloads on Graviton processors, noted Kulkarni.

    While it’s not clear how many applications are being developed to run natively on Arm processors, the process of refactoring existing applications to run on Arm processors is not as intensive for most applications as it was when previously moving applications from one class of processors to another.

    In addition, Kulkarni noted AWS has committed to providing a full range of DevOps services, including a continuous integration/continuous delivery (CI/CD) platform, to help facilitate any transition to Graviton processors.

    There are, of course, multiple strategies for containing cloud costs that range from committing to consuming a specified amount of compute resources annually at discounted rates to relying more on spot instances that are available for limited amounts of time. Regardless of approach, the days when developers were allowed to invoke cloud resources at will appear to have come to an end as enterprise IT organizations become more aware of the total cost of IT. As a result, many of them are adopting financial operations (FinOps) best practices to maximize the utilization of cloud infrastructure resources.

    AWS, like most cloud service providers, gives organizations a wide range of processor options. However, it’s apparent that AWS views Arm processors in the form of Graviton to be the most efficient from both a price and performance perspective. It’s not clear how quickly organizations are embracing Graviton in the cloud given the dominance of x86-based platforms, but it’s apparent there is now a clear alternative for general-purpose workloads. If fact, the more data-intensive those workloads become, the greater the interest in more efficient processor architectures.

    Of course, x86 platforms are not going away anytime soon. But as more Arm-based processors find their way into the enterprise, DevOps workflows will only become more challenging to manage.

  • 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 creates 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 offered.

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

    Monster.com

    REPS & Co.
    Remote
    Senior Software Engineer
    $120,000

    Dice.com

    AIT Global
    Jersey City, New Jersey
    DevOps Engineer
    $120,000 to $130,000

    Indeed.com

    Southwest Airlines
    Dallas, Texas
    Cloud DevOps Engineer
    $118,600

    SimplyHired

    Portrait Displays
    Pleasanton, California
    DevOps Engineer
    $110,000 to $140,000

    LinkedIn

    Peraton
    Chantilly, Virginia
    DevOps Engineer
    $72,500 to $181,300

  • Report Identifies Top 10 Open Source Software Risks

    Report Identifies Top 10 Open Source Software Risks

    Endor Labs, a provider of a platform for managing open source software, published a report that classifies the top 10 open source software risks of 2023. The company published the list as part of an effort to better educate application development teams about issues that can lead to software supply chain compromises. That list includes:

    Known Vulnerabilities: A version of a software component may contain vulnerable code that is accidentally introduced by its developers. When vulnerability details are publicly disclosed, there may not be a patch readily available.

    Unmaintained Software: A software component may not be actively developed or maintained anymore, resulting in patches for functional and non-functional bugs not being provided in a timely manner—if they’re provided at all.

    Name Confusion Attacks: Attackers may create components whose name resembles the names of legitimate open source or system components. This is also known as typosquatting. Bad actors might also attempt to mimic trustworthy authors (brandjacking) or play with common naming patterns in different languages or ecosystems (combosquatting).

    Compromise of Legitimate Package: Attackers may compromise resources that are part of an existing, legitimate project or associated distribution infrastructure to inject malicious code into software components.

    Outdated Software: A project may use an old, outdated version of a software component even though a newer, more secure version exists.

    Untracked Dependencies: Developers may not be aware of a dependency on a component because it is part of another upstream module they employed.

    License Risks: A software component or project may not have a license at all, may have one that is incompatible with the component’s or project’s intended use or whose requirements are not or cannot be met.

    Immature Software: An open source project may not apply development best practices such as having a standard versioning scheme or lacking a regression test suite, review guidelines or documentation.

    Unapproved Changes: A software component may change without giving developers the chance to notice, review or approve such changes because the download link points to an unversioned resource, a versioned resource has been modified or tampered with or due to an insecure data transfer.

    Unknown Origin: Details about the source code, build process or the distribution process of a software component may be unknown or non-verifiable.

    Endor Labs CEO Varun Badhwar said organizations need more visibility in the potential operational risks that come with increased reliance on open source software. That doesn’t mean organizations should use less open source software, but there are issues that many development teams may not always appreciate. A recent analysis of nearly 2,000 software packages published by Endor Labs, for example, found 95% of all application vulnerabilities can be traced back to a transitive dependency created when a developer employed an open source component.

    Regardless of the root cause, responsibility for application security continues to be pushed left toward application developers. The challenge is it’s not possible to achieve that goal without first knowing what issues developers and the DevSecOps teams that support them need to be focused on. Perfect application security is, of course, unattainable, but any reduction in the number of vulnerabilities littering the software landscape will go a long way toward reducing the current level of stress developers and DevOps teams experience.

  • Checkly Adds Monitoring-as-Code to Testing Platform

    Checkly Adds Monitoring-as-Code to Testing Platform

    Checkly this week added a monitoring-as-code (MaC) workflow capability to its software-as-a-service (SaaS) platform that is used to create synthetic tests for applications.

    The Checkly platform spins up browsers to test and can now monitor how applications are performing at both the user interface and application programming interface (API) level. That capability, currently available in beta, is enabled via a command line interface (CLI) for accessing an instance of TypeScript to invoke MaC workflows.

    Checkly CEO Hannes Lenke said that integrated approach enables application development teams to observe applications in as little as 60 seconds without instrumenting them with agent software.

    As part of that effort, Checkly also made generally available Playwright Test, a testing platform for web applications that spins up modern browsers on demand in addition to updating its public dashboards and adding an analytics API.

    Finally, the Checkly SaaS platform has passed a SOC 2 Type II security audit.

    Lenke said the overall goal is to make it simpler for developers to discover and remediate issues as they assume more responsibility for the ongoing management of applications.

    It’s not clear whether developers are taking over responsibility for testing and monitoring applications, but as more responsibility for applications shifts left, organizations are looking to give developers the tools they will require to succeed. That doesn’t mean IT operations teams won’t need to continue to monitor IT environments, but developers do need integrated tools that give them enough meaningful context to address them as they write code. Synthetic testing tools also enable developers to address many routine issues long before they might be discovered by a dedicated testing team that should be focused on ensuring the overall quality of the user experience.

    Regardless of the approach to testing and monitoring, Lenke noted that the silos that make up the software development life cycle are becoming more tightly integrated in modern application development environments. The primary objective is to make it possible for organizations to accelerate application development without compromising quality, he added.

    Of course, the more testing that occurs early in the application development process, the fewer issues a DevOps team should encounter after an application has been deployed in a production environment. The issue is that, historically, much of that testing occurs late in the application development process. Each time a project falls behind schedule, there is naturally a greater temptation to reduce the amount of time spent on testing to ensure the on-time delivery of an application. Providing developers with tools for testing and monitoring applications as they are being built should ensure that the proper level of testing is occurring before an application is deployed.

    There will, however, never be a perfect application. Over time, DevOps teams will discover that every application is impacted by drift to varying degrees as updates are made and the underlying infrastructure is upgraded. The most critical issue is reducing the number of potential issues overworked DevOps teams may need to address later on by ensuring the code being deployed is of the highest quality possible.

  • Sysdig Launches Wireshark Foundation

    Sysdig Launches Wireshark Foundation

    Sysdig this week announced there is now a Wireshark Foundation that will oversee future development of the widely used open source traffic protocol analyzer.

    Gerald Combs, who is now director of open source projects at Sysdig, along with Loris Degioanni, CTO of Sysdig, launched Wireshark in 2006 to enable teams to monitor network traffic, learn protocols and packet basics and troubleshoot network problems. There are more than 2,000 contributors and Wireshark has been downloaded more than 60 million times in the last five years alone.

    The Wireshark Foundation will provide a framework for long-term stewardship and sustainability. The foundation will be led by Sheri Najafi as executive director, and Janice Spampinato, Hansang Bae, Najafi, Combs and Degioanni will serve on the board.
    Combs said rather than donating Wireshark to an existing foundation, it was decided to set one up to formalize many of the community processes that have evolved over the past two decades.

    Degioanni said the foundation will also ensure Wireshark remains relevant long after its creators eventually retire. Wireshark has a graphical user interface (GUI) that provides IT teams with an easy-to-understand traffic protocol analyzer. However, as applications become more distributed, additional types of IT professionals, including DevOps teams, are analyzing network traffic. Similarly, cybersecurity teams are using these tools to help track down the source of anomalous activity.

    It’s not clear whether network operations (NetOps) and DevOps workflows are merging, but the level of collaboration has increased. As networking increasingly becomes software-defined, it’s clear that developers will employ application programming interfaces (APIs) to manage networks as code in much the same way they do infrastructure in the public cloud. Most of those networking APIs are comparatively low-level, but with the rise of services meshes, it’s clear networking services are becoming more accessible.

    The biggest challenge is distinct cultures that have arisen around networking and application development. IT organizations will need to decide whether to provide development teams with the ability to programmatically invoke networking services on their own or through a self-service portal managed by a NetOps team. Regardless of who is responsible for managing the network going forward, the divide between DevOps and NetOps is already starting to narrow. The biggest challenge is simply finding a common language to express core concepts that eliminates any sense of fiefdom that might exist between them. After all, any conflict that arises can usually be attributed to a simple failure to communicate.

    In the meantime, in the age of edge computing, network latency issues are becoming even more challenging. An application based on microservices architecture is especially sensitive to network latency issues that are difficult to troubleshoot over an extended network. Tools that make those issues more obvious are crucial.