devopsy.kinsta.cloud

Category: Features

  • Red Hat Brings Ansible Automation to Google Cloud

    Red Hat Brings Ansible Automation to Google Cloud

    Red Hat today announced that the Red Hat Ansible Automation Platform is now available on Google Cloud to simplify the management of yet another cloud platform.

    Using the Ansible Automation Platform, it’s now possible for IT teams that invoke Google Cloud to access pre-integrated services such as Google Virtual Private Cloud, security groups, load balancers and compute and instance groups.

    Pete Cruz, head of product and technical marketing for Red Hat Advanced Cluster Management for Red Hat, said Google Cloud—alongside existing support for rival cloud services—will make it simpler to consistently apply automation across multiple cloud and on-premises IT environments.

    In addition, IT teams can also count the consumption of the Ansible Automation Platform toward any existing enterprise spend agreements with Google.

    Ansible has emerged as a de facto standard for IT automation and is widely embraced by IT vendors and cloud service providers. That level of support has fostered the creation of a level of automation content that is now unrivaled by any other automation framework, noted Cruz.

    In the meantime, the pressure to automate IT processes is building during uncertain economic times. As IT environments continue to become more complex—thanks, in part, to the rise of cloud-native applications—many IT organizations are finding it more challenging to convince business executives to hire additional full-time employees. As a result, many of those IT organizations are now looking to automate as many processes as possible as more workloads are distributed from the network edge to the cloud.

    Rather than create a single playbook to automate every IT process on an end-to-end basis, organizations generally mix-and-match content created by others to automate workflows across highly distributed computing environments, noted Cruz.

    The biggest challenge when automating IT processes is simply overcoming inertia. Many processes are still manual simply because they always have been. In other cases, IT teams are still relying on undocumented scripts created by IT administrators who have left the organization. As the IT environment continues to evolve, it’s not likely those scripts will continue to scale.

    One way or another, IT is becoming more automated. The irony is that after using IT to automate almost every business process imaginable, it’s only recently that IT teams are getting around to automating their own workflows. Many of the rote tasks that used to be performed by entry-level personnel have been steadily disappearing thanks to automation.

    DevOps teams, of course, have always been ruthlessly committed to automating as many IT processes as possible in the name of efficiency. The rise of Ansible, however, makes it easier for every IT organization to achieve that same goal because they don’t have to wait for a specialist to create a playbook to automate a process. An Ansible playbook that can be easily customized or extended often already exists. The real issue may simply be knowing where to look for it.

  • Automation Challenges Holding DevOps Back

    Automation Challenges Holding DevOps Back

    A survey of 500 IT and engineering leaders in the U.S. published today finds organizations build an average of 6.7 internal applications per year themselves in addition to investing in 7.7 separate platforms to build applications.

    Commissioned by Internal, a provider of platforms for building application development environments, the survey also found organizations are spending 40% of their time building and maintaining these internal tools and workflows. While more than three-quarters (76%) of respondents said that this work is necessary, it distracts from building applications that drive business revenue. A total of 82% said a lack of true flexibility and customization is the top reason so much time is spent on building and managing internal tools and workflows.

    A full 94% of respondents said they want a more collaborative platform that enables technical and non-technical users to build internal tools/workflows faster together. The survey also found 91% of respondents believe a platform that encompasses application development and workflow automation would save development time.

    Internal CEO Arisa Amano said one thing that holds IT teams back is that managing the platforms used to build applications requires too much programming expertise. Internal is making a case for a graphical approach to building application development environments so IT administrators can easily construct them using a drag-and-drop interface on behalf of an application development team. That approach makes it possible to allocate more programming resources to building applications, she said.

    More organizations than ever are revisiting how applications are built as the number of projects increases despite an uncertain global economy, noted Amano. Organizations of all sizes are reluctant to hire additional full-time engineers even as digital transformation initiatives demand a growing number of custom applications, she added. The only way to effectively address those conflicting goals is to adopt a platform that automates much of the workflow associated with building an application development environment, said Amano.

    It’s not clear how willing DevOps teams are to replace the platforms they use today to build those environments, but many organizations are still relying on bespoke platforms they built and continue to maintain. Many of those platforms are made up of a collection of tools that DevOps teams cobbled together over the years. However, many of the software engineers that initially built those integrations may have since moved on and the documentation left behind is likely to be scant, noted Amano.

    Most DevOps teams in 2023 will continue investing in higher automation levels to accelerate application development. The quandary they all face is whether to continue to invest in the platforms they have already or migrate to a platform that makes it simpler to build and maintain an application environment using automated workflows built and maintained by a vendor. Regardless of what they choose, it’s certain the days when organizations could afford to throw engineers at every integration challenge have come to an end.

  • Cisco AppDynamics Survey Surfaces DevSecOps Challenges

    Cisco AppDynamics Survey Surfaces DevSecOps Challenges

    A survey of 1,150 large enterprise IT professionals from the AppDynamics unit of Cisco suggested application security progress is being made slowly and steadily as organizations continue to embrace DevSecOps best practices.

    The survey finds that while more than three-quarters of respondents (76%) believe that DevSecOps is essential for organizations to effectively protect against a multi-staged security attack on the full application stack only 43% reported their organization has already started to implement DevSecOps workflows while another 46% said they are currently considering making the shift.

    More than three-quarters of respondents (78%) also said a lack of a shared vision between application development and security teams presents a challenge to application security over the next 12 months. More than half (55%) said they currently considered security to be more of an inhibitor of innovation than an enabler. Nevertheless, 81% admitted a lack of application security skills and resources is now an issue for their organization, with 79% acknowledging that securing the full application stack is now a priority for their organization.

    A full 92% admitted that the rush to rapidly innovate and respond to the changing needs of customers and users during the COVID-19 pandemic has come at the expense of robust application security. Well over half of respondents (58%) also noted their organization often ended up in ‘security limbo’ because they didn’t know what security issues to focus on and prioritize. A total of 88% acknowledged their organization could be doing more to secure the full stack of modern applications across the entire application life cycle.

    Not surprisingly, 93% said it’s important to be able to contextualize security so that they can correlate risk in relation to, for example, application performance, end user experience and business metrics. However, more than two-thirds (68%) reported that their current security solutions work well in silos but not together. A total of 85% stated that cultural changes to support the shift to a DevSecOps approach are important to improve application security.

    AppDynamics Executive CTO Gregg Ostrowski said it is apparent organizations are still wrestling with not just application security technologies but also people and process issues. The most critical issue is to knock down the silos that exist in organizations that often result in one team demonizing another, he added.

    Overall, application security is becoming more challenging as the attack surface expands. A full 89% of technologists reported that their organization experienced an expansion in its attack surfaces over the last two years, with almost half (46%) noting that this expansion is already increasing cybersecurity challenges. One of the primary drives of that expansion as been the rise of the internet-of-things (IoT) applications (59%), rapid adoption of cloud computing platforms (56%) and digital business transformation initiatives (51%).

    On the plus side, more than three-quarters of respondents (76%) said they believe artificial intelligence (AI) will play an increasingly important role in addressing application security challenges. The issue, of course, is how soon those advances might be made at a time when attacks against software supply chains are clearly on the rise.

  • Jellyfish Adds Tool to Visualize Software Development Workflows

    Jellyfish Adds Tool to Visualize Software Development Workflows

    Jellyfish today unveiled a tool that identifies bottlenecks in software engineering processes using data the company collects via Git repositories and project management software from Atlassian.

    Krishna Kannan, head of product for Jellyfish, said Life Cycle Explorer provides managers with a tool that makes it simpler to identify the root cause of a process breakdown.

    Life Cycle Explorer goes beyond providing simple top-level metrics to calculate the time consumed at each stage of a workflow for any given process and then visually map it to surface trends, noted Kannan.

    That makes it possible to identify gaps, see where work areas overlap—indicating parallel processes—and drill into how outlier events may be impacting the overall life cycle of a development project.

    The launch of Life Cycle Explorer comes at a time when there is more focus on the efficiency of DevOps teams than at any time in recent memory. During uncertain economic times, organizations of all sizes are looking to optimize DevOps workflows to ensure maximum efficiency because many organizations are hesitant to hire additional full-time engineers.

    The important thing to remember when analyzing DevOps workflows is there is no such thing as the optimal “Goldilocks” workflow that can be universally applied, noted Kannan. Instead, most DevOps leaders will discover one team excels at one segment of a DevOps workflow while others are more efficient elsewhere. Life Cycle Explorer makes it easier to identify those best practices in a way that makes them simpler to replicate when appropriate, said Kannan.

    Life Cycle Explorer follows the addition of a benchmarking tool and DevFinOps offering that addresses cost capitalization reporting for research and development. The core Jellyfish engineering management platform is designed to ingest data from the tools an organization already uses to build applications and then applies proprietary algorithms to create a comprehensive view of workflows across an organization. The challenge many organizations encounter today is they often lack visibility into workflows that have each been individually constructed by a diverse range of DevOps teams working on very different types of software projects.

    At the very least, DevOps teams need to establish a baseline that surfaces the current rate at which software development occurs. Once that baseline is established it then becomes possible to measure the impact changes to software engineering practices are having. Today many organizations make educated guesses about what changes are needed without really understanding the impact they might be having across the entire software development life cycle.

    Of course, it will be up to each organization to determine the degree to which they want to measure workflows. The Jellyfish platform makes it simpler to identify workflow issues, but there are also value stream management (VSM) platforms that track the impact software engineering workflows are having on specific business goals. Those VSM platforms are typically much more challenging to implement and maintain. The Jellyfish approach focuses more narrowly on improving the efficiency of DevOps teams.

    Regardless of approach, things that are not measured are not being managed. At a time when organizations are more dependent on software than ever, the need to manage software development life cycle as efficiently as possible has become a lot more important.

  • How To Build Anti-Fragile Software Ecosystems

    How To Build Anti-Fragile Software Ecosystems

    Just as organisms are susceptible to diseases and viruses, software systems are susceptible to hacks and errors. And within many complex interconnected systems, a minor bug could have a cascading effect across an entire organism, causing it to break. As such, increasing the resiliency of a software ecosystem is something engineers continually strive for. But how do we get there?

    One concept to consider is anti-fragile. Being anti-fragile refers to the ability of a system to thrive in adversity and adapt to change. Specifically, with regard to software, anti-fragile can equate to responsive coding practices, such as auto-scaling or default backups, to mitigate unforeseen events. Chaos engineering, for example, is one method to expose edge cases and build with adaptability in mind. And with the introduction of intelligent automation, often fueled by machine learning (ML) and artificial intelligence (AI), it’s becoming more and more feasible to build anti-fragile software systems.

    I recently met with Asim Razzaq, co-founder and CEO of Yotascale and former head of platform engineering at PayPal, to discover what it takes to build anti-fragile software. According to Razzaq, anti-fragile represents the next evolution of reactive, resilient software systems. And introducing anti-fragile concepts into your application networks can be done with just a few (relatively) simple steps. Below, we’ll define what anti-fragile is and see how this concept can be applied to software development and DevOps.

    Understanding Anti-Fragile

    As the adage goes, “What doesn’t kill you makes you stronger.” And it’s true—many natural systems tend to thrive under inhospitable conditions. As described by Nassim Nicholas Taleb in the book ‘Antifragile: Things That Gain from Disorder,’ anti-fragile systems thrive in adversity. For example, consider how human muscle grows under stress and load. Immune systems similarly adapt and respond to new viruses and improve the body’s resilience over time. So, how does this relate to software development?

    Well, organizations need to develop highly-tolerant software systems to meet rising digital consumer expectations. Especially when under extreme loads, systems must be elastic to adapt and survive. To meet high user demands, as well as specific service-level objectives (SLOs) and agreements (SLAs), most software companies are already investing in cloud-native tools that improve reliability. For example, a hallmark of site reliability engineering (SRE) is introducing automation to enhance the stability of applications.

    One example of gauging anti-fragile in software environments is chaos engineering, says Razzaq. Chaos engineering is the act of throwing a wrench into the machine. You randomly introduce bugs and malformed requests and attempt to create as much havoc as possible to see what happens. This could mean pulling out cables and restarting servers to gauge how software systems respond.

    “Software that can respond the best adapts the best,” said Razzaq. For example, if you manually remove a few nodes from the cluster but the system knows it needs seven to function, it could automatically spin up additional nodes. Or if the whole cluster goes down, ideally, the system would automatically restart and scale to the necessary requirements. In essence, anti-fragile software systems can understand and adapt to new environments without much, or any, human input.

    Tips to Construct Anti-Fragile Software Systems

    So, how can we construct anti-fragile software systems — especially when real-world challenges are often unpredictable? Razzaq shared helpful advice to consider when crafting anti-fragile software architecture.

    1. Start With Your Most Critical Systems First

    First, introduce chaos engineering to your most absolute critical systems. Define these vital components at the heart of your product which must remain functional. For a payments processor SaaS, for example, this would be the infrastructure supporting its transactional engine, such as the login and payment microservices.

    2. Determine How to Test Fragility

    Once you’ve identified this critical infrastructure, figure out how to test for fragility in your environment. Introduce chaos engineering to the component to see how it behaves. For example, returning to our payment platform example, this may include switching off a payment transaction type to see how the system functions in an extreme scenario.

    3. Decouple Components

    If systems are too closely coupled, errors and outages can ripple across multiple software services. To avoid that, it’s a good practice to prevent tight coupling between components—especially between critical systems and non-critical ones.

    4. Introduce Alternate Paths

    One method to decouple is by introducing alternate paths. For example, if a credit card verification component goes offline, the system should naturally accept other forms of payment and automatically suggest another form, such as a bank transfer. If all systems are down, the system could still accept unverified payments in a queue and let this continue until the threshold reaches a certain risk level.

    5. Learn From Past Events

    The next frontier of designing anti-fragile architecture is developing self-learning, autonomous systems. Of course, there is a limit to how automation can respond to unforeseen issues. But by feeding a machine learning model with more and more experiences, it could deal with untested new scenarios more gracefully. Of course, AI has the potential to make harmful decisions and even introduce unintentional bias, so organizations should have accountability for the algorithms they oversee, cautioned Razzaq.

    Benefits of Building With Anti-Fragile in Mind

    The goal is to able to thrive and function even under duress. By identifying the elements of core infrastructure to keep alive and putting it through the wringer, you can discover frailties before they cause significant consequences. And by decoupling components and introducing alternate paths, software systems can be better equipped for whatever may come. Uplevelling system operations with increased automation and AI is likely the future of constructing more fault-tolerant applications.

    “Software is everything in this day and age,” said Razzaq. “It increasingly plays a critical role in life-enhancing capabilities.” As such, the end benefits of developing an anti-fragile style could have hugely positive effects. In health care situations, it could make a difference in saving lives. For other less dire scenarios, increased fault tolerance leads to less lost revenue during peak traffic times and more consistent end-user experiences.

  • New Relic Bolsters Observability Platform

    New Relic Bolsters Observability Platform

    New Relic has updated its observability platform to include the ability to better detect and track errors in addition to monitoring vulnerabilities.

    At the same time, an instance of the New Relic observability platform that runs natively on the Microsoft Azure cloud platform is now also generally available.

    Manav Khurana, general manager for observability product and chief growth office for New Relic, said the alliance will enable Microsoft Azure customers to consume New Relic as part of their existing Microsoft Azure services contract.

    New Relic already provides an errors inbox to track issues, but is now adding a tool to track the impact an error might have by correlating data across traces and logs. The company has also integrated its platform with Slack to make it simpler for IT teams to generate alerts when vulnerabilities are introduced into codebases and manage errors more collaboratively.

    Similarly, New Relic is also looking to foster greater collaboration between software engineering and cybersecurity teams. A New Relic Vulnerability Management tool with no additional configuration required captures security signals generated via the company’s Telemetry Data Platform in a way that can be analyzed using an interactive application security testing (IAST) tool that New Relic gained with its acquisition of K2 Cyber Security. Additional IAST capabilities available in preview include the ability to leverage a patented deterministic technique to identify and provide automated vulnerability validation that highlights a proof-of-exploit.

    The overall goal is to provide more visibility and context for organizations that are implementing best DevSecOps practices, said Khurana.

    It’s still relatively early days as far as the integration of observability platforms into DevOps workflows is concerned. A recent survey conducted by New Relic found most organizations don’t expect to have robust observability practices in place by 2025. While most organizations have tools to monitor predefined metrics today, there is a significant gap between observability platforms that enable IT teams to determine the root cause of an IT issue and monitoring platforms that generate an alert whenever a threshold is exceeded.

    In fact, many organizations have too many monitoring tools that often surface conflicting or redundant alerts, noted Khurana.

    One way or another, more codebases are being instrumented. As that process continues to evolve, the agents embedded in that code make it simpler to collect the logs and traces needed to advance observability. The challenge, as always, is that it takes time for the number of fully instrumented applications to exceed the number of legacy applications that are either partially instrumented or not instrumented at all.

    As IT environments become more complex, the need for observability is becoming much more pressing at a time when most IT teams are more short-handed than ever, noted Khurana.

    Regardless of approach, there’s no doubt that observability, with patience, will impact the management of IT for the better.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

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

    LinkedIn

    SiriusXM
    Washington, D.C.
    Director – Client Build and Release Management
    $166,000 to $300,000

    SimplyHired

    Dataflix
    Remote
    DevOps Engineer
    $140,000 to $190,000

    ZipRecruiter

    Bay Systems
    Mountain View, California
    Senior Full Stack Developer
    $120,000 to $174,000

    Monster.com

    GlobalLogic
    Remote
    Senior DevOps Engineer
    $120,000 to $130,000

    Indeed.com

    Leidos
    Ashburn, Virginia
    DevSecOps Engineer
    $97,000 to $202,000

  • Atlassian Extends Automation Framework’s Reach

    Atlassian Extends Automation Framework’s Reach

    Atlassian this week extended its namesake automation framework to include its Confluence collaboration software. In addition, it’s now possible to automatically create bi-directional branches in Bitbucket, GitHub or GitLab platforms from within the company’s Jira project management application.

    At the same time, it’s now possible to automatically generate feature flags from within Jira through integration with the feature management platform created by LaunchDarkly and automate alert and incident responses stemming from the Amazon Web Services (AWS) cloud.

    Dilani Kahawala, head of product for the automation platform at Atlassian, said these extensions to the Atlassian Automation framework are part of a larger ongoing effort to remove the silos within software engineering teams and the rest of the business.

    DevOps teams, for example, will now be able to expand the number of those automated actions being taken because change requests can be automatically created. Atlassian estimated that IT teams will spend 25% less time managing change requests and save 115 hours per month.

    To save more time, templates that automatically create Wiki pages in Confluence can be spun up at the completion of every sprint.

    Since it first launched for Jira in 2020, Atlassian claims more than 10 billion automated actions have been executed across the Atlassian platform.

    Kahawala said as more organizations realize how dependent they are on software to drive revenue, the need to close the divide between software engineering teams becomes much more pressing. She noted that changes to the timetable for one project can have a cascading effect across the entire business. At a time when organizations are counting on digital business transformation initiatives to remain competitive, the speed at which organizations share updates across silos is critical, said Kahawala.

    At the same time, organizations are also striving to become more productive in an uncertain global economy. Automating rote tasks makes it possible for development teams to spend more time writing code, added Kahawala.

    Less clear right now is whether businesses can absorb the pace of change that is enabled by modern software development. Historically, business leaders complained that their dependency on IT was holding the business back because it took too long for IT teams to implement changes. Today, however, many organizations routinely deliver code updates to mission-critical applications daily. While not every delivery may involve a major new update, it’s apparent that the pace of innovation is now occurring at speeds many organizations find challenging to absorb.

    As organizations continue to adopt best DevOps practices, the pace of innovation is only going to accelerate further. The challenge—and the opportunity—is to ruthlessly eliminate as many manual tasks as possible to accelerate the pace of innovation. After all, software engineering pros have better ways to spend their time than manually creating yet another branch in a continuous integration/continuous delivery (CI/CD) platform or, worse yet, reenter data into a project management application.

    Join the makers of Jira for a brand-new (free) Agile & DevOps event. Atlassian Presents: Unleash is designed to help your team collaborate from discovery to delivery to running great software. Get first access and “cheat codes” to the newest Jira Software features and products from Atlassian; network with peers, industry experts, and Atlassian product leaders; and solve real-life challenges around your Jira and toolchain configuration and workflow. Live in Berlin or digitally on February 9. Register for free.

  • Software Supply Chain Security Debt is Increasing: Here’s How To Pay It Off

    Software Supply Chain Security Debt is Increasing: Here’s How To Pay It Off

    Last year, the world woke up to the software supply chain dilemma. We saw a spike in attacks as hackers sought to exploit known and unknown vulnerabilities within dependencies. There is also the chance of typosquatting, and malicious code commits to consider. Such supply chain attacks have increased by a shocking 742% over the past few years.

    It’s easy to let software security debt accumulate, as it’s cumbersome to stay on top of frequent updates — especially when new releases cause breaking change. Furthermore, companies might unknowingly collect security debt by hastily looping in projects whose origin is unknown. Plugging these gaps can bring a high burden down the road, which too often falls on the shoulders of developers to manage.

    I recently reconnected with Dan Lorenc, founder and CEO of Chainguard, to discover why risks in the software supply chain contribute to increased security debt and how organizations can proverbially pay it off. Lorenc is a key figure behind Sigstore, the open source utility built to verify the provenance of open source packages. Below, we’ll consider the state of software supply chain security and examine some modern solutions that lessen its severity.

    Why is Supply Chain Security Debt Rising?

    Modern software ecosystems are an intricate mosaic of dependencies, and supply chain security concerns often arise at the cracks between them. “It’s about the gaps and hand-off points between individuals in the software life cycle,” said Lorenc. Since these hand-off points can threaten systems at large, they can accumulate considerable security debt if left unguarded.

    Another reason why security debt is increasing, said Lorenc, is that fixing issues is rarely incentivized—it’s always thought of as “someone else’s problem.” Minimizing this debt will require organizations to change this mindset and follow modern security best practices, like implementing multifactor authentication infrastructure and more frequent code reviews. It will also take a coordinated effort from package managers to integrate tooling that helps verify the legitimacy of packages, said Lorenc.

    Solutions to Reduce Software Supply Chain Security Debt

    Automated Vulnerability Scanning

    In addition to advancing internal culture toward greater security awareness, organizations will benefit from automation that enhances the discovery of vulnerabilities. Because when a severe incident like Log4j hits the presses, it’s a mad scramble to respond. Even a year later, one in four downloads still possesses the infamous vulnerability.

    Integrating automated security scanning is the first step to knowing how these incidents impact your security posture. A tool like Snyk can do a great job of surfacing known vulnerabilities and finding where they lie within your software stack and provide remediation advice. Continually checking for updates can also help pay off security debt “as you go” instead of upgrading everything all at once, says Lorenc. But although scanning tools are essential for increasing visibility, they don’t address the root cause of why they are vulnerabilities in these packages in the first place, says Lorenc.

    Checking Transitive Dependencies

    Reports find that 95% of vulnerabilities stem from transitive dependencies. These are dependencies that are buried deep within the dependency tree of another package. And depending on the programming language, they’re not always that visible. The combinatory effect of transitive dependencies can lead to exponentially more vulnerabilities and issues if not carefully tracked. And since they’re running locally with the same privileges as your other packages, you shouldn’t treat these vulnerabilities any differently, said Lorenc. “You need to realize they can affect your application in the same way.”

    Validating The Source

    The link between the package manager and the source code is a frail area that warrants additional verification. Social engineering tricks can effectively trick users into downloading insecure packages that appear safe at the outset yet hide corrupt code. Or, account takeovers can result in attackers inserting malicious code into commonly used open libraries. Package managers often host built versions and forked versions of software produced by the community on GitHub, yet do not validate a clear link to the original repository. This gap heightens the chance for a malicious package to slip through the cracks, says Lorenc.

    This is something that Sigstore, the open standard for signing, verifying and protecting software, aims to accomplish. In mid-2022, Sigstore was implemented within Kubernetes, signaling the adoption of Sigstore as a standard throughout the open source ecosystem. It’s also been adopted by Npm and PyPI and Maven Central will soon support Sigstore as well, said Lorenc. Although some of these moves have received pushback from developers, Lorenc argued that such verification is necessary to help link packages to their source and increase credibility for open source dependencies.

    Chipping Away At Security Debt

    Like technical debt piles up over time, security debt can quickly rise if left unchecked. Chipping away at increasing software supply chain security debt will likely require a “pay as you go” approach wherein developers continuously scan and update their dependencies. One good sign is that people are paying more attention to risks latent within their code, and the industry is discovering and sharing more potential vulnerabilities before they are exploited.

    “Security has advanced, and there are common best practices across the industry,” said Lorenc. But if these practices aren’t followed, it could bring dire consequences for the organizations and the industry as a whole. And although Sigstore can help bridge the disconnect between the package managers and the source code, there are plenty of other techniques to help improve a security footprint for open source software and cloud-native infrastructure. For example, SLSA and greater use of SBOMs can help address security debt more holistically.

    The software supply chain security dilemma is an advanced topic that requires a coordinated effort from various stakeholders to remedy. The important takeaway is to stay positive, see the debt, and pay it off incrementally, says Lorenc.

  • GitLab Strengthens Remote DevOps Management

    GitLab Strengthens Remote DevOps Management

    GitLab this week moved to provide remote developers with access to a more secure continuous integration/continuous delivery (CI/CD) platform while at the same time adding a dashboard that makes it simpler to track the overall status of application development projects.

    David DeSanto, chief product officer for GitLab, said GitLab Remote Development takes advantage of an instance of the GitLab CI/CD platform running on a Kubernetes cluster. That cluster is accessed via a Web-based integrated development environment (IDE) to eliminate the need for developers to create development environments on their local desktops.

    That capability reduces developers’ time and effort on tasks other than code and gives organizations more centralized control over the intellectual property being created, noted DeSanto. Organizations will no longer have to worry, for example, about theft of a developer’s laptop that has sensitive data on it, he added. In addition, organizations will be able to more easily create “golden” images that can be consistently accessed by developers residing in multiple locations.

    In addition to making it easier to centrally manage a distributed team of developers, GitLab is also adding a GitLab Value Streams Dashboard that provides senior executives with access to metrics that assess the overall health of an application development project. While GitLab has always provided metrics to DevOps teams, DeSanto said this dashboard, available as a private beta, makes it possible to identify, for example, bottlenecks that might result in delayed delivery of an application.

    Value stream management (VSM) is, of course, not a new idea. The issue that DevOps teams are trying to come to terms with is whether they need to adopt a dedicated VSM platform. The other option is to simply provide a set of dashboards that enable senior IT and business executives to track projects’ progress without deciphering a set of much lower key performance indicators (KPIs). Previously, the GitLab platform surfaced a lot of nitty-gritty details that don’t provide the context senior executives required, noted DeSanto. The Value Streams Dashboard metric surfaces KPIs based on DevOps Readiness Assessments (DORA) metrics from Google alongside other flow metrics.

    These latest offerings are part of a larger case being made for an integrated DevOps platform that reduces the total cost of application development by eliminating the need for organizations to integrate various tools themselves. Each DevOps team can employ as many of the modules GitLab makes available as they need. Once invoked, they take advantage of the same data store as every other element of the GitLab platform. That capability is becoming more critical as organizations embrace platform engineering to reduce the cost of application development using DevOps best practices, said DeSanto.

    It’s not clear how much interest there is in replacing legacy CI/CD platforms that, in some instances, have been in place for nearly a decade. However, as the pace at which applications are being built and deployed continues to accelerate, there is no doubt that organizations of all sizes will need to modernize application development processes.