Application and API security (AAS) has been around as a unified security toolset for several years now, and it is near revolutionary in the breadth of coverage that it offers. Products in the space perform application-layer distributed denial of service (DDoS) protection, account takeover protection, API security, web app security, and more. As the products and their various functionality have been merged, advanced security has become possible too—things like data leak prevention that can watch for super slow data exfiltration attacks and application security that is informed by API security.

AAS Tomorrow

Even with all that these tools do, customers are demanding more. We’re seeing a convergence of all production-side security in one place and the possibility of even development security ending up folded into offerings. Indeed, some products already offer static application security testing (SAST), aka source code security scanning.

One-Stop Security Shop
On the surface, consolidating every security issue under the sun into a single product or platform may seem to limit best-of-breed choices and create a single location for attackers to target; however, there are benefits to this expanding approach. We will dispense with the obvious case of customers wanting a single responsible vendor. This is true of broad offerings of any kind: that subset of customers is both the driving force and the target market. But for AAS there is far more.

Inclusion of Development Security Capabilities
For example, the deep integration of SAST drives AAS quality up. And offering API security tools–often merely a check of the interface with little or no evaluation of the underlying code–in combination with SAST provides information about that very underlying code. If an API call passes security testing based on results, it may not be obvious that there is an underlying security flaw in the source just waiting to be exploited.

SAST specializes in looking for known vulnerabilities in source code and helping developers to fix them. It also knows about risky, but not inherently insecure, coding practices in a given file. That information, passed on to the web application firewall (WAF), can be used to create protections for the web app or, when passed on to the API security feature, can be used to forcibly limit response ranges for given variables.

Development security offers SAST, dynamic application software testing (DAST), interactive application software testing (IAST), and often runtime application self-protection. It’s focused more on the development side of DevOps, and SAST/DAST are sometimes even integrated directly into the integrated development environment (IDE). This is the other half of application security, and now that we’re seeing spotty inclusion of SAST and DAST in AAS products, we hope the trend continues until customers that would like it can have a one-stop security shop. Of course, the key has to be “customers that would like it.”

Inclusion of SBOMs
If we were to compile our dream list of features, the first thing we’d want to see added would be software bills of materials (SBoMs). While every security vendor under the sun creates SBoMs these days, we’d like to see AAS vendors import the two primary SBoM formats—software package data exchange (SPDX) and CycloneDX (CDX)—and use them as part of the overall security and protection environment.

The critical part of SBoMs is their ability to identify all of the libraries and open source components in an application’s build tree. This information can then be used to check against known vulnerabilities and inform the entire application security architecture as implemented in the AAS.

Plenty of security products have this functionality, but it has not taken off yet in the AAS market. Even with vendors that can generate a SBoM, it’s not well-integrated into the process. Yet with its great potential, we hope this soon becomes table stake functionality for AAS solutions: generation and/or import along with using the SBoM information across the spectrum of security services the platform offers.

In Security, More Information is Always Better

Essentially, in security, more information is always better. Traditionally, AAS tools (like the WAF and API security tools the market grew out of) look at security from the active attack/defense perspective. That is a good way to look at it, and considering that many of the vendors’ products were and are application delivery tools also, they have a wealth of runtime attack and protection information. However, security starts with the first line of code, and adding in that perspective simply increases the opportunities not only to actively defend the application but to proactively make the application more secure in the process.

There are many quality security tools out there, and we would hope any market-leading vendor would allow an enterprise to pick and choose which products do each part of the job. That will take time because integrating a dozen or so products across a single platform is not something that happens overnight, and certainly not with the depth that the current single-vendor solutions have.

That is, however, our hope for the long-term future, and we do seem to be headed that way.

Next Steps

To learn more, take a look at GigaOm’s AAS Key Criteria and Radar reports. These reports provide a comprehensive overview of the market, outline the criteria you’ll want to consider in a purchase decision, and evaluate how a number of vendors perform against those decision criteria.

• GigaOm Key Criteria for Evaluating AAS Solutions
• GigaOm Radar for AAS

If you’re not yet a GigaOm subscriber, you can access the research using a free trial.

The post The Evolution of Application and API Security (AAS) appeared first on Gigaom.

One step that, in hindsight, was natural and is highly likely to continue, is basing GitOps on a continuous delivery (CD) tool or a deployment automation tool. This allows the GitOps tool to be more tightly aligned with the actual rollout process and placed at the end of the DevOps toolchain.

Likewise, aligning with “worker” tools allows GitOps to focus on the coordination of a rollout rather than the work of the rollout, as underlying workers like FluxCD and ArgoCD handle a lot of the deployment and configuration and can be told what to do for things they don’t specifically know.

Security and Compliance in GitOps

The fact that GitOps handles all of the final steps to deployment, and even deployment to production, means that the tool will hold an increasingly critical place in the DevOps hierarchy. The best place for security policy enforcement is in the tool that will set up the final, complete solution. It’s also the best place to focus on compliance. Where better to build a software bill of materials (SBOM) than at the tag end, when you know what the software, support applications, environment, and even the OS are loading up?

We expect vendors to continue folding in security, and we expect that the tooling will do a better and better job of it. At the same time, we see this space increasingly involved in active—or runtime—security. GitOps can already watch for changes to config as they’re pushed, but we see vendors moving toward monitoring the running application to detect change, and running the processes to keep them in line with the system of record, eliminating drift caused by things like installations on the running system.

The Future of GitOps

This space will likely end up as a feature set in other products—not because it isn’t important enough to remain a separate space, but because the trend of bundling with CD tools or configuration management tools is already pretty set, and we expect similar consolidations to continue. This will keep the solution set stable, but we hope won’t completely lock in the feature set to a single CD tool.

Customers will rightly be concerned by the failures and ownership changes that this space has recently seen. However, we consider the risk to be minimal at this point. There are a lot of reasons that we don’t think customers should worry too much—primarily because, at this point, bundling with other tools is the norm for remaining products, and that will buffer revenue concerns while GitOps is taken up.

GitOps Methodology: Beyond the Technology

GitOps, like DevOps, is as much a methodology as technology. You absolutely need the tools to enable it, but without a culture that promotes end-to-end deployment automation, the best infrastructure as code (IaC) and GitOps tools won’t solve the problems.

This is why we recommend that prospective customers study the GitOps process separately from studying tools before making a large commitment. Understanding how and when all of the moving parts, like network configuration and app testing, fit into the overall GitOps architecture will help a lot when choosing a product that suits your organization’s needs, and training is available from a variety of places.

Is DIY GitOps Worth It?

Some organizations may want to use GitOps but do not wish to bring on another vendor. Like so many parts of IT, GitOps can be done in-house, it will just take more work—both up front and in long-term maintenance. GitOps tools are enablers and standardizers, so both the enablement and standardizations will have to be implemented and maintained independently if an organization wishes to run homebrew GitOps.

A large number of companies have tacked GitOps methodologies onto DevOps practices as changes in the GitOps space—like pull-based approaches, for example—force them to consider if they want this newer technology and how to get it implemented. While pull-based tools exist, a full GitOps solution would be less complex than integrating a separate tool into an internally developed GitOps toolchain. For this specific example, some organizations will be well positioned—via Argo, for example—but there is an array of improvements in the space that create similar issues for homebrew solutions.

The Final Case for GitOps

Simply put: the benefits of GitOps far outweigh the risks and implementation costs. The ability to easily check in a code or configuration, build all that needs building, apply policies (both corporate and security), build a deployment environment and deploy the application into it, kick off dynamic testing if required, and even promote to production if a specified set of conditions are met is powerful. GitOps solutions offer stable releases by ensuring each release meets standards defined both in the GitOps tooling and in tools like security scanners that are integrated into the GitOps process.

IT is a complex environment, and exceptions do and will exist, but as a rule, GitOps has grown to the point that it can handle more than 90% of IT needs and even more in a cloud-first environment.

Next Steps

To learn more, take a look at GigaOm’s GitOps Key Criteria and Radar reports. These reports provide a comprehensive overview of the market, outline the criteria you’ll want to consider in a purchase decision, and evaluate how a number of vendors perform against those decision criteria.

• GigaOm Key Criteria for Evaluating GitOps Solutions
• GigaOm Radar for GitOps

If you’re not yet a GigaOm subscriber, you can access the research using a free trial.

The post From Here to GitOps and Back Again appeared first on Gigaom.

A GitOps approach can provide a range of benefits to organizations. The toolset used to manage applications, infrastructure, and operational elements should be simplified. Changes are driven by the source control system, so staff can drive many downstream actions via source control tools. Managing infrastructure and operational resource definitions in source control also provides additional semantics and controls for these elements compared to a non-GitOps approach. For example, infrastructure configurations can be branched, versioned, reviewed, tagged, refactored, validated, unit-tested, and so on in the same way that application code is.

All changes are traceable and auditable, can have additional context available from commit messages, and can have access or other policy rules applied to them. Organizations adopting GitOps may also benefit from increased agility and reliability because they can safely ship new code, scale, and adapt more quickly. Finally, GitOps allows organizations to improve their security posture as processes are simplified and codified and attack surfaces reduced.

Because of the evolution of FluxCD and ArgoCD, the market is increasingly focused on the value add of policy management and creation. Our analysis considers this market focus.

A GitOps toolchain assumes a version control tool, CI/CD tools, and centralized reporting. While not required, GitOps is far more useful with container registries and change control processes over repositories, though traditional infrastructure cannot be ignored.

This is our third year evaluating the GitOps space in the context of our Key Criteria and Radar reports. This report builds on our previous analysis and considers how the market has evolved over the last year.

This GigaOm Radar report examines six of the top GitOps solutions and compares offerings against the capabilities (table stakes, key features, and emerging features) and nonfunctional requirements (business criteria) outlined in the companion Key Criteria report. Together, these reports provide an overview of the market, identify leading GitOps offerings, and help decision-makers evaluate these solutions so they can make a more informed investment decision.

The post GigaOm Radar for GitOps appeared first on Gigaom.

Modern applications need a comprehensive security capability that covers all points of vulnerability. This means a combination of what we have seen in traditional web application firewalls (WAFs), plus all the protection offered by API security and API management products. Together, these types of protection create a comprehensive application and API security (AAS) solution category.

Application deployment architectures have also changed—applications can be spread across multiple clouds, running in Kubernetes, hosted in a data center, or co-hosted with a vendor. AAS products must protect all important parts of the overall application, wherever they are deployed.

Critical to protecting modern applications is understanding them. AAS products provide two tools to help understand and validate an application via its APIs. The first is API “import from definition,” whether in WSDL, OpenAPI, or another standard. This helps us to understand what the API should be doing. The other is “runtime detection” of APIs, which covers what the API is doing. It also offers a view of APIs that are outside the system and do not have a valid API definition file—which often make up the majority of an organization’s APIs.

As application architectures became more complex, the sophistication and volume of attacks increased as well, causing a litany of issues for IT staff. The volume of attack data, the number of attack vectors, and dispersion of attack activity all make protecting applications harder. AAS products must either block known and identifiable attacks outright or offer advanced filtering of data that’s escalated to IT staff to keep the volume of alerts at a manageable level.

There are many attack vectors, some requiring unique protection capabilities. The AAS space requires that application-layer distributed denial of service (DDoS) attacks be protected against while other well-known attacks are detected and/or blocked at the same time—even though these two types of protection generally use different detection and remediation techniques.

Integration with security information and event management (SIEM) solutions allows this critical piece of application security to be included in post-mortem and even secondary detection generated and managed on the SIEM solution.

This is our third year evaluating the AAS space in the context of our Key Criteria and Radar reports. This report builds on our previous analysis and considers how the market has evolved over the last year.

This GigaOm Radar report examines 13 of the top AAS solutions and compares offerings against the capabilities (table stakes, key features, and emerging features) and nonfunctional requirements (business criteria) outlined in the companion Key Criteria report. Together, these reports provide an overview of the market, identify leading AAS offerings, and help decision-makers evaluate these solutions so they can make a more informed investment decision.

The post GigaOm Radar for Application and API Security (AAS) appeared first on Gigaom.

In practice, this means many applications are now being developed as collections of API calls. An application is often some UI code and a collection of back-end APIs. The increasing use of containers only exacerbates this division. Indeed, microservices are largely enabled by container architectures. As a result, modern application security must address protecting both of these unique access points—front-end UI and back-end APIs—to protect the entire application.

Traditionally, application security and API security were viewed as totally different areas. However, the needs of the market have driven them together because, generally, one is not deployed without the other. Application and API security (AAS) encompasses both of these concerns as a single service. This has created some interesting overlap, as AAS is traditionally purchased and still largely used by IT security teams, but DevOps teams have an increasing interest and stake as they take on greater involvement in infrastructure and security.

This report is focused on universal application protection, which includes protecting applications traditionally, as with a web application firewall (WAF), as well as protecting APIs the way security API management products do. For the runtime protection portion of products in this space, the report also considers what new and unique protection might be offered based on the merging of the application and API security fields. In addition, this report also considers the increasing use of artificial intelligence (AI) and machine learning (ML) to implement features such as runtime application self-protection (RASP) via next-generation firewalls (NGFWs). At this time, AI is driving most of the changes in this technology space, as in other security- and testing-focused spaces.

Figure 1. AAS Overview

AAS solutions today need to protect applications and their underlying APIs not only from traditional attacks like SQL injection but also from more subtle attacks that may include several stages and different attack vectors all in one. The tools must be adaptable enough to protect modern digital applications across the range of their architectures and deployment environments. The ability to work with the standard reporting and processing tools of the modern enterprise is vital.

This technology space is closely related to API security, and organizations that have a WAF or NGFW implementation that they are happy with should consider those solutions. Note that some development security solutions also offer real-time protection, and organizations should consider where to place that functionality.

Business Imperative
Attacks are increasing against any application exposed to the world, and those attacks are increasingly automated, with AI being used to evaluate weaknesses in specifically targeted organizations and attack responses. Protecting both applications and APIs that are accessible to the world is imperative and drives the adoption of comprehensive application security tools that include API security. Organizations that are happy with their WAF or NGFW might be happy with API security tools, and those with solid API security might want to fill the gap with an NGFW. However, in both scenarios, the result is similar to implementing a single AAS solution. Organizations looking to implement or replace both API security and WAF functionality will be best served by considering the vendors in the AAS space.

Sector Adoption Score
To help executives and decision-makers assess the potential impact and value of an AAS solution deployment to the business, this GigaOm Key Criteria report provides a structured assessment of the sector across five factors: benefit, maturity, urgency, impact, and effort. By scoring each factor based on how strongly it compels or deters adoption of an AAS solution, we provide an overall Sector Adoption Score (Figure 2) of 3.8 out of 5, with 5 indicating the strongest possible recommendation to adopt. This indicates that an AAS solution is a credible candidate for deployment and worthy of thoughtful consideration.

The factors contributing to the Sector Adoption Score for AAS are explained in more detail in the Sector Brief section that follows.