devopsy.kinsta.cloud

Category: Continuous Testing

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.

  • Codenotary Automates SBOM Creation

    Codenotary Automates SBOM Creation

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

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

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

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

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

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

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

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

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

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

  • Rust Momentum Intensifies | Elon Says No WFH

    Rust Momentum Intensifies | Elon Says No WFH

    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: People won’t shut up about Rustlang, and Musk mandates Twitter teams return to the office. (more…)

  • GitHub Previews Free CI/CD Migration Tool Due in 2023

    GitHub Previews Free CI/CD Migration Tool Due in 2023

    At its GitHub Universe event, GitHub today unveiled a bevy of updates to its cloud service, including a forthcoming set of migration tools. The tools will automate migrations from legacy continuous integration/continuous delivery (CI/CD) platform to GitHub Actions.

    GitHub Actions Importer is already being used by a small group of enterprise IT organizations to migrate workflows and template the GitHub CI/CD platform.

    Damian Brady, senior manager for developer advocacy at GitHub, told conference attendees that these free tools will become more broadly available in 2023. GitHub Actions Importer will be distributed as a Docker container that manifests itself as an extension of the GitHub command line interface (CLI).

    One of the biggest challenges the company has faced in driving adoption of its platforms is that many DevOps teams don’t want to rebuild the templates and workflows they are already using on their existing CI/CD platform, he noted.

    Other GitHub Actions extensions include native integration with software development tools for building internet-of-things (IoT) applications and support for personal access tokens (PATs) that enable more granular control over permissions and repository access.

    Other security capabilities include expanded access to audit log events in the enterprise edition of GitHub, an ability for maintainers of open source repositories to privately share vulnerability reports and support for Ruby as one of the programming languages now supported by a CodeQL tool for discovering vulnerabilities.

    Additional extensions to existing services for developers also were previewed, including an ability to interact with the GitHub Copilot tool for automating code writing using voice commands. Dubbed “Hey, GitHub!” the tool is available as an experiment being advanced by the GitHub Next research team.

    Finally, the company previewed enhancements to code search-and-view capabilities in the Codespaces tool that will now be made available for free for up to 60 hours per month to developers.

    GitHub claims its CI/CD platform is now being used to process 10 million builds a day, most of which are employing code accessed via its repository. It’s not clear how that compares to other CI/CD platforms, but it’s apparent the GitHub Actions CI/CD platform has gained a significant amount of traction as GitHub continues to make a case for creating tighter integrations between its repository and CI/CD platform. GitHub is also clearly signaling it will spend a lot more time wooing organizations that already have a legacy CI/CD platform installed.

    In the meantime, the next era of DevOps has arrived as workloads become both more complex to build and deploy across highly distributed computing environments. Many of the CI/CD platforms that organizations deployed are now straining under the weight of multiple customizations and extensions that have been made over the years. Each DevOps teams will need to decide whether maintaining those platforms makes the most technical and economic sense or if they should migrate to a more modern platform.

    Regardless of what they decide, one thing that is certain is that DevOps teams won’t be getting larger, so the need to invest in higher levels of automation has become pressing.

  • SRE Survey Reveals Major Technical and Cultural Challenges

    SRE Survey Reveals Major Technical and Cultural Challenges

    Catchpoint, in partnership with Blameless, today published an annual survey of 559 site reliability engineers (SREs) that found 59% of respondents didn’t view tool sprawl to be a major concern. Another 40% said tool sprawl is a moderate (33%) to serious problem (8%).

    More than half of respondents said they build as much as 30% of the tools they use themselves, with more than half (54%) noting their organization tracks three or more different types of telemetry data to drive observability. The top three types of telemetry data collected are infrastructure (62%), application (58%) and network monitoring (55%) and, on average, the survey suggested the median toil level of SREs dropped 5% year-over-year.

    Just under half of respondents (46%) also noted they saw no or low value from artificial intelligence for IT operations (AIOps) compared to 30% that have seen moderate to high value. Another 25% are still unsure.

    Finally, the survey concluded that organizations that have adopted a “just culture”—where organizations ensure that incident reporting is not met with punitive measures—are 500% more likely to be Elite performers in terms of the DevOps Research and Assessment (DORA) metrics defined by Google.

    Leo Vasilou, director of product marketing for Catchpoint, said that the survey results provided some insights into the challenges SREs face as they strike a balance between trying to achieve DevOps goals and the fact that hiring has become more constrained during an economic downturn.

    That stress, however, has less to do with managing toolchains than it does ensuring that applications driving critical business processes are consistently available, he noted.

    SREs have emerged as a distinct DevOps function in recent years, focused almost exclusively on programmatically managing the dependencies that exist between a wide range of applications and the underlying infrastructure upon which they depend. Optimizing applications in the cloud-native era has become more challenging because the number of dependencies that exist between the microservices that make up a modern distributed computing environment continues to exponentially increase. In many cases, applications are continually added to IT environments without a commensurate increase in the overall size of the SRE team.

    Regardless of the economic climate, hiring and retaining SREs remains a challenge given the demand for IT professionals with those skills. Of course, there is no formal SRE certificate that is widely recognized so who qualifies to be an SRE tends to vary from one organization to the next. The one thing that is generally agreed upon is that SRE automate a wide range of tasks that would otherwise require multiple IT administrators to perform. Glassdoor also reports that, on average, an SRE makes north of about $125,000, which ranks among the highest salary level within any IT organization.

    Each organization, depending on their geographic region, would need to determine how many IT administrators they could replace if they hired an SRE. That doesn’t mean IT administrators that rely on a wide range of graphical tools to manage IT tasks are going away any time soon, but as DevOps continues to evolve, the dynamics between SRE and IT administrators also will continue to evolve.

  • Standardizing Federal Cybersecurity With DevSecOps

    Standardizing Federal Cybersecurity With DevSecOps

    DevSecOps is having a moment in the federal government. With President Biden’s Executive Order on Improving the Nation’s Cybersecurity and federal agencies’ issuance of DevSecOps best practices based on the Enduring Security Framework, government organizations are shoring up and standardizing their DevSecOps processes to meet today’s cybersecurity challenges head-on.

    Integrating security into the development process is particularly important for federal agencies that have invested significant time, effort and money in creating and running software development factories. These agencies are actively trying to balance security and innovation–and many are succeeding. The United States Air Force’s Kessel Run program is an example of a tightly run and innovative software factory.

    The question is: How can they continue this success as the calls for standardized cybersecurity grow increasingly louder?

    The Delicate Balance Between Security and Innovation

    It’s tough to balance security and innovation and wrap them both in a standardized process. It’s certainly not impossible, as Kessel Run proves. But it does require a high level of rigor to ensure that applications are being developed at speed while taking the necessary time to mitigate and minimize security risks and vulnerabilities. 

    Projects like Kessel Run and others work well in part because they bake security into the development process from the outset. That core tenet of DevSecOps allows teams to integrate and standardize security throughout their development cycles without losing momentum. 

    But, there are challenges to these standardization efforts that are inhibiting DevSecOps practices. 

    First, many government agencies are still working with legacy systems and toolsets rather than the modern technologies that many commercial companies that employ DevSecOps have access to. These technologies can include everything from collaboration platforms, to messaging applications, to underlying platforms that tie all the work being done together. 

    Second, despite the government’s commitment to innovation, old ways of thinking still persist in many pockets of the public sector. Some important people still think, “Why change when email has worked just fine for all these years?” Those people fail to immediately see the value of modernizing their toolsets and practices.

    But outdated technologies and processes won’t help government agencies balance security and innovation–and they won’t work with new cybersecurity policies and mandates. For instance, president Biden’s EO is filled with allusions to ensuring visibility into software development practices and the software supply chain. Doing both requires developers, security managers and operations managers to be on the same page and in constant communication at all levels of the development cycle. 

    Maintaining Situational Awareness Throughout the DevSecOps Process

    Yet even in the most mature DevSecOps environments, this isn’t always possible. Because while DevSecOps is driven by collaboration, that doesn’t mean that developers, security managers, and operations managers always know who’s working on what, or what the status of a particular project is at all times. This is particularly true in a government setting where old processes, technologies, and siloed teams are still present.

    But maintaining the balance between security and innovation is highly dependent on being able to have unfettered situational awareness throughout the development lifecycle. For example, a developer needs to know if a security operations teammate is working on fixing a vulnerability the developer discovered during testing. Likewise, an operations manager needs to know the status of the patch, as that might impact other factors important to the development process, including time to deployment.

    High-level dashboards help all team members quickly ascertain the status of projects in development and are useful in helping individuals understand where things exist in the pipeline. They can provide a quick, at-a-glance take that leaders can use to plan their projects, discover backlogs or potential roadblocks to deployment, and more.

    But even dashboards are not necessarily enough, because stakeholders need to be able to quickly and securely communicate status updates to each other.

    Collecting Communications, Facilitating Collaboration

    The problem is that not all of these individuals will necessarily be using the same tools. Some might be using one messaging service. Others might be holding impromptu video meetings. Others might be posting updates to project management boards. Software development is a living and agile process, and communication is happening all the time through different channels.

    That’s why it’s critical for agencies to pull all of these disparate threads together, especially if they are to properly manage security and maintain compliance with the EO. A single missed communication about a software vulnerability could end up becoming tomorrow’s SUNBURST attack. There must be a way for all DevSecOps stakeholders to interact with each other, regardless of their choice of tools or the channels they’re using.

    This is where the choice of modern toolsets and platforms comes into play. Pulling disparate threads together to facilitate better communication and collaboration requires technologies with the ability to connect various services, automate task management and alerts, and break down any lingering communication silos. It requires an underlying architecture that connects all key stakeholders so they can collaborate and ensure the security of the applications they’re working on. 

    Meeting the Cybersecurity Moment

    Older technologies and practices aren’t up to the moment government agencies are facing. They are unsuitable for today’s software development processes, and will not aid in the quest to stay ahead of today’s cyber threats.

    To meet the moment, government agencies must embrace new ways of communicating and collaborating. They must use the tools that are available to keep innovating even while standardizing according to cybersecurity regulations. They must provide their DevSecOps teams with the ability to work freely yet securely and set them up for success.

  • Cisco Adds Open Source Tool to Validate Serverless Functions

    Cisco Adds Open Source Tool to Validate Serverless Functions

    Cisco has launched an open source project, dubbed FunctionClarity, that makes it possible to verify signatures before code is deployed in a serverless computing environment.

    Vijoy Pandey, vice president of emerging technologies and incubation at Cisco, said that one of the application security issues that has emerged in serverless computing environments is the lack of validation capability to verify code signatures prior to deployment. As more organizations employ serverless computing frameworks, the overall software supply chain becomes less secure, he noted.

    FunctionClarity includes a command line interface (CLI) tool to invoke a verification function that can be deployed on the Amazon Lambda serverless platform to address that issue; support for Microsoft Azure and Google Cloud serverless platforms is planned, he added.

    The FunctionClarity project aims to close that gap by employing either a keyless approach using open source sigstore tools or a traditional encryption key, noted Pandey.

    The FunctionClarity project is the latest extension of a Cisco OpenClarity initiative that includes an existing project for securing application programming interfaces (APIs) using a service mesh, dubbed APIClarity, and a tool for detecting and managing software bills of materials (SBOMs) and vulnerabilities in container images and filesystems dubbed KubeClarity. All three projects are part of an ongoing Cisco effort to contribute code to the open source community that, while essential, does not provide a lot of differentiated value for any one vendor, said Pandey.

    The FunctionClarity project arrives at a time when concerns over the security of software supply chains is on the rise. Many of the software security issues that organizations are encountering stem from the simple fact that developers can provision cloud infrastructure without any kind of meaningful cybersecurity review. Code signing, within the context of a larger set of DevSecOps workflows, is now starting to gain traction to better ensure secure software supply chains. The challenge is that as more code winds up running on serverless computing platforms, a need to extend the reach of whatever approach to code signing an organization adopts becomes more evident.

    In general, the open source community is collectively trying to respond to an executive order issued by the Biden administration that required federal agencies to implement a series of steps to better secure their software supply chains. One of those measures includes wider adoption of code signatures to ensure the authenticity of code being incorporated into applications. The challenge is that incorporating code signatures into DevOps workflows has historically not been a trivial process to implement. Most recently, a free sigstore cloud service launched that promised to make it easier to achieve that goal.

    It’s not clear how widely or even how rapidly code signing will be adopted, but enterprise IT organizations are paying close attention to how federal agencies are responding to the executive order. Many of the tools and processes defined by those agencies will inevitably be copied by enterprise IT organizations that have thus far made limited use of code signing to verify the authenticity of software components. The challenge now is finding a way to achieve that goal without slowing down the rate at which modern software is developed.

  • Developer’s Guide to Fuzz Testing

    Developer’s Guide to Fuzz Testing

    Fuzz testing continues to grow in popularity among developers within the open source community. Google’s open source security (OSS) team recently reported finding more than 40,000 bugs in 650 open source projects through the use of fuzz testing. But if you have no clue what fuzz testing is (yet), don’t worry. You’ve come to the right place.

    What is Fuzz Testing?

    Fuzz testing is a dynamic testing method for finding bugs and security issues in software. During a fuzz test, a program or a function under test gets executed with invalid, unexpected or random inputs to uncover unlikely or unexpected edge cases. 

    Value of Fuzzing for DevSecOps 

    As we know, DevSecOps extends the approaches of DevOps and Agile by adding suitable security testing methods alongside every phase of the software development life cycle (SDLC), creating a dynamic and continuous testing process. 

    Part of that testing process can and should involve fuzzing to detect security and stability issues at all phases of the SDLC and empower developers to ship software quickly and securely. For example, to prevent regressions from going live by running automated fuzz tests on every code change.

    Especially in the automotive industry and complex embedded projects, where a lot of untrusted and complicated data gets processed, fuzzing brings excellent benefits to DevSecOps. Indeed, developers can apply fuzzing similar to unit testing to automatically test their security-critical modules for potential vulnerabilities. But with fuzzing on an integration level, they can also cover all the complicated and dangerous edge cases that can occur in the interaction between different modules. 

    Fuzz Testing Benefits

    Fuzzing code generates thousands of automated test cases in a second, with the fuzzer receiving in-depth feedback on code coverage and the program states reached to simulate the interaction of different modules during the execution of the source code. The fuzzer can adapt and mute its inputs based on runtime feedback in the following iterations to maximize code coverage. Some of the benefits are:

    1. (Almost) no false positives: If you find a crash, fuzzing provides you with the error source and the malicious input that caused the issue. So, you can be sure that each finding is a real vulnerability.
    2. Debug reproducible findings: Modern fuzz testing tools will provide you with the input causing the issue, including the source of the error. With this, you already have a lot of helpful information to reproduce the bug and load it directly into the debugger. 
    3. Find issues in forgotten edge cases: Because fuzzing is executing a program with invalid or random input, it also uncovers unlikely and unexpected edge case errors that would not otherwise have been revealed.

    Who Uses Fuzz Testing?

    As cybersecurity regulations and standards continue to expand globally, more and more organizations are extending cybersecurity programs and running automated security testing before they ship software. Whole industries, especially those that involve advanced quality and security regulations, are setting standards for security testing that recommend fuzz testing, including automotive, aviation, finance, healthcare, telco and energy.

    Digging deeper into the automotive industry, for example, a variety of International Organization for Standardization (ISO) and other organizational standards now recommend fuzzing:

    Best Practices

    The most effective way to do security testing, fuzzing included, is to do so continuously. This means integrating fuzzing right into your CI/CD pipeline. Doing so creates quick feedback cycles so developers can fix security vulnerabilities before the code is shipped. Integrating fuzzing tools into code hosting systems like GitHub is also valuable. Doing so allows communication and alerts to be shared across your DevOps team as soon as a problem is uncovered, which helps to facilitate fixing vulnerabilities. 

    What Bugs Can I Find?

    While the practice remains relatively new, fuzzing has already discovered thousands of bugs across different use cases. Bug and vulnerability types discovered include:

    • Remote code executions
    • Injections, which can be triggered by untrusted inputs 
    • Memory leaks: Incorrect memory allocation 
    • Exposure of sensitive data: Accidental exposure of personal data
    • Functional bugs: Inputs that are not being responded to 

    and many more bugs, such as undefined behavior, uncaught exceptions and buffer overflow. Learn more.

    Getting Started

    You can try out an open source fuzzer, like Jazzer (for Java testing) or the CI Fuzz CLI (for C/C++ testing). When you’re comfortable with fuzzing and want to use this approach in more complex environments, enterprise solutions offer added features like API fuzzing, reporting and CI/CD integration. 

    So give it a shot and join the community of open source developers using fuzzing to quickly and securely ship their software. 

  • Gitpod Looks to Drive Application Development Into the Cloud

    Gitpod Looks to Drive Application Development Into the Cloud

    Gitpod today revealed it will add an application programming interface (API) to make cloud development environments (CDEs) more extensible. Gitpod also said Johannes Landgraf assumed the role of single CEO for Gitpod, as the previous co-CEO, Sven Efftinge, becomes the company’s first technical fellow.

    Fresh from raising an additional $25 million in funding, Gitpod’s Landgraf said that API will make it easier to build plug-ins for CDEs. In time, Landgraf said, CDEs will become as accessible as any development environment running on a local desktop.

    Software engineers typically waste five hours a week maintaining application environments, noted Landgraf. Via an open source development platform, Gitpod automates the provisioning of secure workspaces in the cloud that provide the added benefit of making it easier for multiple developers to collaborate, he added.

    Capabilities added to the GitPod product roadmap include dramatically faster startup times, improved resiliency and a Gitpod Cloud offering for larger companies as well as a preview environment and workflows that foster collaboration. Gitpod also announced it passed a SOC2 Type II security audit.

    Today, the Gitpod platform is being used by more than 750,000 developers at organizations such as Shopify, Stripe and Slack, noted Landgraf.

    One of the longstanding issues that has always been problematic when building software is that code that runs on a local desktop doesn’t always work when deployed in a production environment. The Gitpod API will make it simpler to spin up various platforms and tools whenever a developer accesses a CDE. The goal is to make it possible to more closely replicate the production environments on which developers will ultimately deploy their applications, noted Landgraf.

    In addition, a CDE should reduce the amount of data that developers routinely move between laptops and cloud computing environments as they build more complex applications, he added.

    In the wake of the economic downturn, there is a lot more focus on developer productivity these days, especially as organizations look to accelerate their of digital business transformations. DevOps teams are also keen to find ways to centrally manage developer experience at a time when many of those developers continue to work from home, said Landgraf.

    It’s not clear to what degree CDE will replace integrated development environments (IDEs) running on a local machine, but all the major cloud service providers are encouraging developers to build applications in the cloud where their applications will run. The challenge is that many of those offerings tend to lock developers into a specific cloud platform, noted Landgraf. Most developers today are building applications that need to be deployed across multiple clouds, he added.

    One way or another, software development is increasingly shifting to the cloud. Most organizations will likely try to find a balance between the amount of code developed on a local machine that developers can just fire up when the mood strikes and the amount of code developed in the cloud. The most immediate challenge is to make sure the CDE experience is every bit as good as the existing local IDE.

  • Octopus Deploy Tightens Integration With GitHub Actions

    Octopus Deploy Tightens Integration With GitHub Actions

    Octopus Deploy announced today it has tightened the integration between its automated deployment platform and GitHub Actions continuous integration/continuous deployment (CI/CD) platform.

    Harsh Sabikhi, senior vice president of revenue for Octopus Deploy, said GitHub Actions for Octopus Deploy v2 adds support for a push-build-information-action capability GitHub added to its platform that enables DevOps teams to track commits, builds and issues. That information is now also synchronized with a DevOps Insights tool from Octopus Deploy that surfaces metrics based on the DevOps Research and Assessment (DORA) metrics defined by Google.

    Other capabilities added to the integration include support for semantic versioning release tags within workflows, job summaries and a revamped user interface that makes GitHub easier to access from within Octopus Deploy.

    Sabikhi said that while GitHub Actions provides some deployment capabilities, the automation platform created by Octopus Deploy automates application release management across multiple clouds and on-premises IT environments. GitHub Actions is optimized for managing CI processes within the context of a Git-based workflow emanating from a cloud service managed by GitHub, he added.

    The integration with GitHub Actions makes it simpler to extend those Git-based workflows across multiple deployment platforms, noted Sabikhi.

    GitOps is, essentially, a more opinionated approach to DevOps that relies on an instance of the open source Git repository as the single source of truth about the environment rather than a set of application or server configuration files. GitHub views GitOps as a means of extending a code repository into the realm of DevOps workflows using the GitHub Actions platform.

    As organizations embrace GitOps, however, many are finding it advantageous to more loosely couple CI and CD platforms. Integrated CI/CD platforms have been around now for more than a decade, but few organizations have been able to truly automate the delivery of applications using those platforms. Platforms such as Octopus Deploy have been created from the ground up to specifically manage deployments of applications. In addition to GitHub Actions, Octopus Deploy also provides integrations with multiple other CI platforms to enable DevOps teams to mix and match CI platforms as they best see fit, said Sabikhi.

    It’s not clear how many DevOps teams are willing to acquire a separate CD platform, but as applications become more challenging to build and deploy in the cloud-native era many organizations are revisiting the DevOps processes they used to build and deploy monolithic applications. The challenge is many of them have spent years defining workflows based on legacy CI/CD platforms, so there is a lot of existing inertia that would need to be overcome when adopting a dedicated CD platform.

    It’s clear that CD is finally becoming more achievable using platforms that automate much of the process. Each DevOps team will need to decide how many staff they want to dedicate specifically to managing those CD platforms; the pace at which applications are being deployed should accelerate as application release management becomes more automated.

  • Update to Open Source ZAP Tool Improves DAST Performance

    Update to Open Source ZAP Tool Improves DAST Performance

    An update to the OWASP Zed Attack Proxy (ZAP) open source dynamic application security testing (DAST) tool made available today improves performance by employing a multi-threaded passive scanner engine.

    Version 2.12.0 of ZAP also adds support for HTTP/2 and should make it simpler to update the vulnerability scanning tool by making the spider that discovers new resources an add-on that is now capable of discovering more URLs.

    ZAP is an open source penetration testing tool maintained by the Open Web Application Security Project (OWASP) designed specifically for testing web applications.

    Simon Bennetts, founder and chief maintainer of ZAP, said the latest update will make it simpler for developers to discover vulnerabilities in their code faster. One of the reasons developers often don’t frequently scan their code for vulnerabilities is because the scans are perceived to be slow, he said. Of course, the longer a developer waits before scanning their code the longer it will take to complete the scan.

    DAST tools are a critical element of any DevSecOps workflow because they enable developers to view weaknesses in application security as an attacker would—by analyzing a web application through its front end. That approach doesn’t eliminate the need for static application security testing (SAST) tools to discover vulnerabilities in source code; rather, a DAST tool helps developers better understand how cyberattacks target specific types of vulnerabilities in their applications, noted Bennetts. As an open source tool, ZAP is intended to remove the barriers to adoption of DAST tools by making it simpler for developers to download and install themselves, he added.

    Interest in DAST tools is, of course, rising in the wake of a series of high-profile attacks against software supply chains. The debate that has ensued is how far to shift application security responsibility left toward application developers. More organizations are starting to require developers to embed security tools within their application development tools. Others are also embedding various types of security tools within their DevOps workflows to ensure scans are run should developers fail to do so.

    No developer sets out to build an insecure application, of course. The primary issue is that many of the DAST tools being provided are not designed to be employed by developers, said Bennetts. Instead, they are designed for cybersecurity teams that then share results with developers after an application has been constructed, he added. That approach creates a dysfunctional relationship between application development and cybersecurity teams because developers are being asked to remediate vulnerabilities long after code was initially written, said Bennetts. In most cases, those developers have moved on to other projects so any context for how code was constructed is often lost, he noted.

    Implementing DevSecOps best practices is, naturally, as much about culture as it is the tools being provided. However, the one thing that is clear is that tools adopted willingly by developers are going to be much more widely used than tools chosen by others on their behalf. In many cases, the shortest path to improving the overall state of application security is going to be an open source tool that developers can readily access themselves.