devopsy.kinsta.cloud

Tag: API

  • Postman Employs Browsers to Simplify API Collaboration

    Postman Employs Browsers to Simplify API Collaboration

    Postman today announced it is making its namesake platform for managing application programming interfaces (APIs) available via a browser to make it easier to share and inspect APIs. Previously, Postman required DevOps teams to download a desktop application to access the Postman platform.

    Kin Lane, chief evangelist for Postman, said agent software developed by Postman makes it possible to create a proxy application to facilitate API request-sending at scale that overcomes the cross-origin resource sharing (CORS) limitations of browsers.

    DevOps teams can now simply attach a URL to an API that is shared with any other member of the team. Clicking on that URL exposes the API in a way that makes it possible to not only visually inspect it but also employ the Postman platform to make sure rules and policies have been applied appropriately.

    That capability also makes it possible to onboard new users to an API project in addition to eliminating the need to manage updates to the desktop application, added Lane.

    Now that more organizations have adopted an API-first approach to building and deploying applications in the age of microservices, those APIs need to be managed as discrete projects. Postman provides a means of achieving that goal now through a browser interface that can be accessed more easily by members of DevOps teams working remotely.

    Postman claims its platform has now enabled more than 1 billion API requests, with more than 48 million API collections now running on Postman. Overall, the company claims there are now more than 11 million users from roughly a half-million organizations on its platform. As the number of microservices-based applications being deployed increases, the number of internal-facing APIs that need to be managed increases exponentially. New functionality can be added to the application without changing the API. In fact, changes to the API are likely to be more disruptive than changes to the application.

    At the same time, cybercriminals are now targeting APIs that are often misconfigured in a way that exposes potentially sensitive data via an open port. As such, security teams are starting to focus more on ensuring processes are in place that ensure APIs have been reviewed before being deployed in a production environment.

    Fresh of raising another $150 million in funding to create a $2 billion valuation, Postman has emerged as a major API management platform in a crowded field that has experienced a wave of consolidation over the last few years involving acquisitions made by Red Hat, Oracle, Salesforce and Microsoft. Each of those acquisitions was made to enhance the API management capabilities of a specific platform. However, it would appear a large percentage of organizations prefer to manage APIs independently of any specific platform.

    Clearly, APIs are core to the implementation of DevOps processes. If those APIs are flawed, the impact on DevOps process can be far-reaching. Continuously validating APIs as they are deployed and updated is not just a best practice,  but it’s also a matter of survival at a time when complex distributed application environments have never been more loosely coupled.

  • How API Testing Can Save You Thousands

    How API Testing Can Save You Thousands

    API testing before launch can mean the difference between a $25 cloud database bill and a $30k bill

    Usage-based billing is a popular payment model in cloud-based SaaS platforms. The idea is that you only pay for the amount of data your project uses, which is great for companies that have finite metrics on their usage amount.

    It’s like getting a glass of water from your kitchen sink. Every time you open the faucet, you know your water bill will go up a few cents (actually much less than that, but for example). So let’s say the water faucet is the cloud platform and the glass represents your API requests.

    One of the ways organizations rack up exorbitant usage-based bills is from critical mistakes in the API request code. For example, your neighbor asks for a glass of water and you fill 10 glasses, or you forget to turn the faucet off after you fill the glass. This is very similar to what can happen in usage-based billing on SaaS platforms, especially for cloud-based API requests.

    An Expensive Example of Data Requests Gone Wrong

    A crowdfunding app in Colombia known as Vaki was shocked to receive a $30,000 USD bill from Google Firebase, due to some pretty simple mistakes. The company had rushed its product to launch, then noticed the app was running incredibly slowly after a version merge.

    Vaki had two choices: either take down the website or try to debug the app in a race against the money-clock. The company chose the latter option and discovered that its API was coded in such a way that with every visitor to their site, it needed to call every document of payments to see the number of supporters of a campaign or the total collected, on every page of the app.

    In other words, the company sent more than 40 billion requests to Firestore in less than 48 hours—an immensely costly mistake, although Vaki managed to work it out with Google in the end. One problem is that Vaki worked on the code while the site was already live, when any of these tools for API testing may have helped the company find the problem before launch.

    It is very important that tech teams debug every request to servers before release. Analyze if the number of requests and data transfer make sense and if your company will support the costs of the host with a big load of traffic. Otherwise, you will just catch loops or un-optimum requests with a huge bill or with your site down.

    API Learnings From Mistakes

    While cloud-based databases such as Amazon, Google Cloud and Microsoft Azure provide a pay-per-hour model, Firebase bills based on a 100k-250k read/write/delete requests to the database. So technically if you stay within this range, your bill shouldn’t amount to more than $25.

    But this also means you need to have perfect code with no mistakes or loops. Vaki was reading every document entry in a certain collection to calculate the total collected and support values for each time a user looked at a particular view.

    In other words, if a crowdfunding campaign had 100 donations, the app would call to the database once, but the reading would equate to 100 reads twice, which means a total of 200 read requests.

    Obviously, when you hit something like 2 million views on a campaign, the read requests to the database will very quickly exceed the billions. And to Google’s credit, this isn’t a get-money schemed it cooked up because it’s very easy to stay within the target metrics.

    In Vaki’s case, it was a simple human error in the data structure that wasn’t optimized for efficiency, and eventually, the company would’ve run into other problems, such as maxed out database connections.

    How to Keep Usage-billing to a Minimum

    Hosting apps today are fairly cheap, but databases can quickly grow out of control if they aren’t optimized efficiently. When it comes to traffic flow between the different parts of your application, read and write requests are the most frequent occurrence in the entire flow.

    So even though the front end may be fast to boot, it’s your backend that needs to be checked, especially as serverless architectures don’t typically offer backend data sessions. So as the backend requires more space and processing power, your overall bill increases.

    There are a few key takeaways from all this. One is that you’ll need to re-think your approach to how your data will have an impact on the total number of reads and writes, and how much processing power is required, which basically means optimizing your code for efficiency and long-term stability.

    The other takeaway is the importance of testing your API before launch, so that you can catch the sort of flaws that Vaki experienced before the product actually goes live.

  • OpenLegacy, Boomi Simplify Legacy Application Integration

    OpenLegacy, Boomi Simplify Legacy Application Integration

    OpenLegacy, a provider of a platform through which application programming interfaces (APIs) are layered on top of legacy application processes, announced today an alliance with Boomi, an arm of Dell Technologies that provides organizations with access to an integration platform-as-service (iPaaS) that is made available as a cloud service.

    Zeev Avidan, chief product officer for OpenLegacy, said the company’s core platform enables IT teams to convert legacy application processes into microservices that can be involved by tools such as Boomi using an API. Rather than merely providing access to an application, OpenLegacy is designed to capture all the business logic, metadata and associated middleware associated with a specific business process executing on, for example, an IMS or AS/400 platform, he said.

    The Boomi alliance extends that capability to include processes created by either citizen integrators or developers via the Boomi cloud service. That’s critical because most mission-critical applications in the enterprise still run on legacy platforms. Rather than having to rewrite those applications from scratch, Avidan said OpenLegacy makes those applications more easily accessible to other applications and platforms via a software development kit (SDK) based on Java.

    At a time when many organizations are looking to accelerate digital business transformation initiatives, Avidan said being able to programmatically invoke an entire business process accelerates the rate at which those initiatives can be completed because business processes don’t necessarily have to be re-engineered.

    In the case of Boomi, that capability is now being extended all the way to end users to make it feasible to tap into existing business processes using a set of tools that already have been adopted by more than 11,000 organizations.

    OpenLegacy is making a case for DevOps teams to think in terms of legacy business processes rather than individual applications. Historically, many organizations have relied on enterprise service bus (ESB) platforms to integrate applications. However, a DevOps team still has to manually integrate all the software components that make up a business process once application environments are connected.

    Legacy platform integration in the absence of OpenLegacy becomes the digital equivalent of an archaeological dig, said Avidan, noting many organizations wind up hiring expensive systems integrators to accomplish the task.

    In the wake of the COVID-19 pandemic, there is clearly a lot more interest in modernizing business processes. Many employees are working from home for the foreseeable future. Cloud services such as Boomi provide a means of enabling end users to craft workflows on their own. The challenge has always been finding a way to easily connect those workflows to transaction processing systems and other systems of record around which the business depends.

    It’s not clear to what degree providing that level of access will drive a burst of business process innovation. However, DevOps teams that spend an inordinate amount of their time integrating new applications with legacy business processes might be keen to leverage an approach the promises to turn those business processes into a reusable microservice.

  • Camunda Extends Reach of BPM Platform

    Camunda Extends Reach of BPM Platform

    Camunda, a provider of a business process management (BPM) platform written in Java, this week added support for an open application programming interface (API) to make it easier to integrate its namesake software with applications written in Javascript/Node.js, Python and C#.

    Company CTO Daniel Mayer said at a time when many organizations are investing in digital business transformation initiatives, the latest updates to the Camunda BPM platform adds support for an OpenAPI standard advanced by The Linux Foundation to enable IT organizations to integrate business processes spanning modules created using different programming languages. In the case of Camunda, IT organizations will be able to generate a REST API client using their preferred coding language that can be integrated with the core Camunda BPM platform, he said.

    In addition, Camunda announced that version 7.13 of the Camunda BPM platform will be available in the form of a lightweight distribution, dubbed Camunda BPM Run, that can be deployed as a Docker container to create a standalone engine with no Java or application server knowledge required.

    Camunda has also added support for Camunda’s Optimize 3.0 to provide a unified view of real-time process insights from any data source and the ability to visually track changes across different versions of process models using its Cawemo tool.

    Finally, Camunda has added support for version 1.3 of the Decision Model and Notation (DMN) specification as well as version 1.2 of the Friendly Enough Expression Language (FEEL) defined by The Object Management Group.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, many organizations are looking to reduce costs by streamlining business processes. The decision many of them need to make is determining to what degree they want to rely on packaged applications to achieve that goal versus a platform that enables them to create custom business processes. While many rote processes can be automated using packaged applications, Mayer said the Camunda platform makes it possible to create business processes that truly differentiate organizations from rivals. Packaged applications, in contrast, drive organizations to employ the same business processes in the same way.

    Of course, organizations can customize packaged applications. However, at that point, most of them will have embarked on an application development project that would be easier to complete using a platform designed for that purpose, he noted.

    Naturally, there are other platforms for integrating business processes that revolve around graphical user interfaces. Camunda has been making the case for an open source Java-based platform that enables developers to create and deploy custom business processes using best DevOps practices at a much lower total cost. The company also commercially makes available an enterprise edition of its platform. In total, Camunda claims there are now than 100,000 developers participating in the Camunda community.

    It’s too early to determine to what degree organizations will rely on packaged applications versus BPM platforms to drive digital business transformation initiatives. However, given the current economic climate, it’s apparent these projects have never been more urgent.

  • Cisco Moves ACI Strategy Forward

    Cisco Moves ACI Strategy Forward

    Cisco is advancing its hybrid cloud computing strategy with release of version 5.0 of Cisco Application Centric Infrastructure (ACI), a software-defined networking (SDN) that can be deployed on cloud platforms or networking equipment deployed in an on-premises IT environment.

    The latest version of Cisco ACI adds support for a transit gateway between virtual private cloud (VPC) instances on the Amazon Web Services (AWS) cloud to provide a more efficient means of routing traffic across east-west and north-south cloud computing environments.

    Cisco is also extending the networking services it provides for the Microsoft Azure cloud to include VNET peering within the Azure Virtual Network, shared service deployments, additional service automation functions.

    Via ACI 5.0, IT teams are now provided a centralized view of cloud resource inventory within AWS and Microsoft Azure along with status indicators and a set of wizards to simplify configurations.

    Cisco also has deepened the level of integration between Cisco ACI and Kubernetes as well, to increase the level of scale that can be achieved in IT environments based on platforms such as VMware vSphere.

    Finally, Cisco has added support for role-based access control (RBAC) in multi-tenancy environments along with two-factor authentication (TFA) capabilities enabled by the Cisco DUO platform. Cisco also added a more flexible policy construct, dubbed Endpoint Security Group (ESG), that can be employed to group endpoints based on L3 attributes and apply contracts between ESGs.

    Srinivas Kotamraju, senior director for product management for Cisco ACI, said the latest update to the SDN platform provides IT teams with the equivalent of many of the same networking services that Cisco historically has provided in an on-premises IT environment.

    Cisco has been making the case for a hybrid cloud computing approach to delivering network services that enables IT teams to manage those services via a central console. Rather than having to manage networking services provided by each cloud service provider, Cisco ACI makes it possible to deploy the same SDN across multiple clouds and on-premises IT environments. Cisco contends that approach ultimately serves to reduce the total cost of delivering networking services by both centralizing management and making it easier to automate the management of networking services across multiple IT environments.

    There are two primary ways Cisco exposes those networking services. DevOps teams can take advantage of application programming interfaces (APIs) to programmatically invoke ACI services. Alternatively, Cisco provides network managers access to a graphical user interface (GUI) through which they can access a command-line interface (CLI) to configure a specific router or switch.

    Kotamraju said with the rise of DevOps the number of organizations giving developer programmatic control over networking services continues to rise. It’s too early to say to what degree NetOps and DevOps teams might ultimately converge; however, Kotamraju said finding ways to meld those two groups is being discussed more frequently within many IT organizations as applications become more distributed.

    Of course, the biggest challenge when it comes to achieving that goal will be more cultural than technical. However, as networking services become more accessible via APIs, it’s now more a question of when and how than if.

  • Netlify Makes Build Plugins Available for Jamstack Platform

    Netlify Makes Build Plugins Available for Jamstack Platform

    Netlify, at a Jamstack Conf Virtual event, announced the general availability of open source Netlify Build Plugins that provide IT teams with a set of continuous integration/continuous delivery (CI/CD) workflows for building websites and web applications using JavaScript, application programming interfaces (APIs) and static HTML files without employing web servers, otherwise known as a Jamstack.

    Designed to be launched from within a Netlify platform to enable IT teams to build a website and launch it from a Git repository to a content delivery network (CDN), the Netlify Build Plugins are intended to make it easier to employ DevOps processes using, for example, a plugin to run an end-to-end Cypress test.

    Netlify CEO Mathias Biilmann said DevOps teams also can make use of a Netlify API to create their own plugins. Ultimately, the goal is to foster the development of a wide range of open source Netlify plugins that would be built and vetted by the Jamstack community, he said.

    Other Netlify Build Plugins provide a means to enable Ghost, an open source headless content management system based on Node.js that can be deployed on any framework; launch a Sentry tool to automatically discover, triage and prioritize bugs; or enable a Gatsby tool to create incremental builds on Netlify.

    A survey of more than 3,000 Jamstack developers published today by Netlify finds one-third have worked on sites serving millions of users over the last year. Nearly two-thirds of survey respondents (62%) work outside the tech industry, including advertising and marketing (21%), media and publishing (14%), education (14%), financial services (13%) and business support and logistics (13%). Well over a third (38%) work for a technology company. About a quarter (26%) have more than 10 years of experience.

    Top Jamstack benefits cited by all types of developers are performance, uptime, speed of development, security, compliance and avoiding vendor lock-in, the survey finds.

    Biilmann said Jamstack as a philosophy enables IT teams to separate the development of front- and backend websites and applications in a way that allows organizations to embrace best DevOps processes. That approach is agnostic as far as any specific JavaScript framework is concerned, but it does define a way to automate the build process for a web application or website.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, more organizations are investing time and resources in modernizing their websites and applications. With more employees and end users depending on those websites to drive digital business processes, the quality of the application experience has become a much bigger concern. At the same time, end users have now come to expect those application experiences to be updated regularly, which in many cases will necessitate the adoption of best DevOps processes.

    In fact, it’s arguable that organizations that don’t embrace best DevOps practices to build and deliver web applications at scale will soon discover they have bitten off more than they can chew.

  • Kong Brings Collaboration to Designing APIs

    Kong Brings Collaboration to Designing APIs

    Kong has launched an open source tool for designing application programming interfaces (APIs) designed to make it easier for teams of developers to collaboratively edit an API specification that can be stored in a Git repository.

    Based on the open source Insomnia API management platform the company gained last year by acquiring Floating Keyboard Software Inc., the Insomnia Designer tool for designing APIs integrates natively with the testing capabilities embedded in the Insomnia API management platform to make it easier to collaboratively design both REST and GraphQL services.

    As part of that effort, Kong is also releasing plugins that enable teams to automatically embed Kong Gateway policies directly into their API specification files within a Git repository.

    Greg Schier, technology tech lead for Insomnia at Kong, said the goal is to streamline the workflow for designing APIs by enabling teams to share updates to edits of API specifications using best GitOps processes.

    For example, DevOps teams can now search for API designs to discover details such as Git Status and Git Branch. They also can automatically generate configurations for both Kubernetes and Kong for Kubernetes within the individual API spec file. Developers can also select Kong plugins that provide capabilities such as authentication or rate-limiting to govern their API’s behavior.

    As organizations embrace microservices-based applications the need to be able to design, build, deploy and maintain APIs has become more critical. Each microservice within an application exposes its own APIs. Organizations that embrace microservices soon find they need to potentially build thousands of APIs. Rather than address each of those API as an isolated project, Kong is making the case for constructing a set of workflows that make it easier to design and construct APIs within the context of a larger DevOps process.

    The goal should be to eventually make the testing of APIs a natural extension of the unit testing process embedded within a continuous integration/continuous delivery (CI/CD) platform, said Schier.

    Within far too many organizations the designing and building of APIs is still an afterthought. There is naturally a lot of focus on building microservices, but once they are constructed not nearly as much attention is paid to the API. And yet, while microservices frequently are replaced, it is the API that remains constant. All the dependencies between the microservices that make up an application are only manageable because of the APIs employed to connect them all. Rather than constructing APIs after a microservice is built, Kong is making the case for consistently designing and building APIs in keeping with best DevOps practices.

    In the wake of the COVID-19 pandemic, it’s hard to say at what rate organizations will be building and deploying new applications. What is for certain is the bulk of new applications will be based on cloud-native microservices to make them more flexible and resilient. That way when the next major crisis erupts, organizations will be able to respond more adroitly to rapidly changing business conditions because the enterprise architecture now revolves around APIs.

  • Compuware Shifts Mainframe App Testing Left

    Compuware Shifts Mainframe App Testing Left

    Compuware today announced it is making it easier to shift application performance testing further left on to the shoulders of developers by adding support for a REST application programming interface (API) to its application performance management (APM) platform for mainframe applications, along with a plug-in for Jenkins continuous integration/continuous delivery (CI/CD) environments.

    Sam Knutson, vice president of product management for Compuware, said during the current economic downturn brought on by the COVID-19 pandemic, organizations will find it is now more imperative to shift more responsibility for managing all aspects of application development toward developers. Many organizations simply won’t be able to afford to retain IT specialists such as application testers, said Knutson.

    Instead, most organizations soon will be looking to automate as many aspects of DevOps as they possibly can with an eye toward enabling developers to achieve goals with as little intervention as possible from IT operations teams, he noted.

    In addition, Knutson said the trend of convergence between mainframe and distributed computing teams within IT organizations is about to accelerate. In fact, there may soon be no such thing as “mainframe DevOps,” he noted; rather, the mainframe will be just another mainstream platform on which applications are deployed.

    The economic downturn may limit the number of new mainframes being deployed. However, given that the total cost of computing on the mainframe tends to be lower than distributed systems, the number of workloads running on existing mainframes could increase as organizations deploy more Linux-based applications on the venerable platform.

    The API Compuware is adding to its Strobe APM platform will help accelerate the development and deployment of those applications by making application testing a more integrated element of a DevOps workflow, said Knutson. Automated tests can be run within the code delivery pipeline using Compuware Topaz for Total Test, the Topaz Utilities plugin or Compuware Hiperstation. Development teams can be notified when performance tests are completed via communications tools such as Slack and Microsoft Teams.

    Knutson said Compuware decided to build a plug-in for Jenkins because it is the most widely deployed CI/CD platform in mainframe environments.

    Despite the pending merger with BMC Software, IT organizations can count on the fact that the Compuware portfolio of DevOps tools for mainframe environments will continue to be supported and updated, he said, pointing out that this latest announcement represents the 22nd consecutive quarterly update to the Compuware portfolio of DevOps tools for mainframes.

    It’s too early to say what precise impact the economic downturn may have on DevOps adoption in mainframe environments. However, it’s safe to say that doing more with less is going to be the order of the day for some time to come. As such, the rate at which IT organizations that rely on mainframes to run their mission-critical applications will be embracing best DevOps practices is likely to increase.

    In fact, rather than incurring the costs of replacing those mainframe applications the priority now is much more likely to be modernizing them as much and as soon as possible.

    — Mike Vizard

  • How to Compare and Contrast APIs to Improve DevOps Processes

    How to Compare and Contrast APIs to Improve DevOps Processes

    The cloud is driving digital transformation, from web applications to mobile applications, from partner integrations to API monetization. Even custom applications are moving into the cloud. If you draw a line through all these trends, APIs would be at the heart of it all.

    We know we need to eat our vegetables to keep our heart healthy, but sometimes it is easier to order takeout after a long day of work. Healthy API hygiene works the same way. In a perfect world, developers would register their API specifications and blueprints in an API catalog, and they would keep them up-to-date as the application changes. But this is a tedious manual process, and sometimes after a long day of work it is easier said than done.

    An API catalog is critical for improving the DevOps process through quality assurance and testing. Furthermore, the production environment for APIs can be subject to even harsher and more hostile access and usage patterns compared to the Dev and Test environments, which tend to be more self-contained. The good news is that by maintaining an API catalog, DevOps can gain more visibility into the contrast between these environments to identify gaps that should be closed. The end result is an improved DevOps process that drives the production of better products and services.

    There are a number of approaches to creating an API catalog, from manually logging APIs into Wikis, spreadsheets and vendor solutions, to more automated discovery tools. An API catalog should include meta information, such as the creator, the date it was last modified, which application it belongs to and so forth. At a deeper level, an API catalog should also include the parameters such as the data type, the bounds for the data type, the transport mechanism, the authentication and authorization mechanism, and a brief description about the data carried within the parameter.

    Compare and Contrast APIs from Dev to Test and Test to Production

    During the application testing phase, which is subject to quality assurance, regressions, performance and interaction cases, an API catalog should be updated and compared against its development state. The contrast between the development API catalog and those generated from the test environment can help identify:

    • An API listed in the Dev catalog, but not in the Test catalog, which would indicate that QA has not tested the API or its payload; therefore, the QA process could be improved.
    • An API listed in the Test catalog, but not the Dev catalog, which would indicate that the Dev catalog was incomplete; therefore, you cannot assume it is a “golden” image. This also suggests an area for improvement in the DevOps process because the developer has not maintained an up-to-date API catalog. Automated tools can help even more here since they generate an API catalog where there is none.

    There is a third scenario, where an API isn’t recorded in the Dev catalog, and it doesn’t show up in the Test catalog, but may later show up in the production traffic. This is considered an unpublished or “out of spec” API.

    Likewise, when moving from test to production environments, the API catalog should be updated to mirror real-world application access. The contrast between the Production API catalog and the Test API catalog can help identify:

     

    • An API listed in the Test catalog, but not the Production catalog, which could identify an API that is not being used. This would indicate that QA testing did not align with the real-world use of the application and suggest that development cycles could be prioritized elsewhere.

     

    • An API listed in the Production catalog, but not in the Test catalog, which would indicate the API catalog did not capture the most up-to-date specification. This is one example of a Shadow API, an API that was intended to be part of the application, but has not gone through the required processes related to testing and application security.

     

     

    Additionally, identifying an API in the Production catalog, but not in the Test catalog can be useful in identifying threat actors searching for vulnerabilities to exploit an unpublished API.

    Comparing and contrasting dev, test and production environments can help identify opportunities for improvement. However, manually creating and maintaining an API catalog is often neglected because of its tedious nature. DevOps needs automated tools to help discover APIs, generate blueprints and store them into the catalog. It is too much of a burden for developers to manually document APIs, but a continuously updated API catalog is the most important key to derive success using the compare and contrast methodology.

    — Ravi Balupari

  • 42Crunch Extends API Security Alliance With Microsoft

    42Crunch Extends API Security Alliance With Microsoft

    42Crunch this week announced it has extended an existing alliance with Microsoft to now include support for Microsoft Azure Pipelines for its REST API Static Security Testing Tool. Previously, 42Crunch only provided support for the Microsoft Visual Studio integrated development environment (IDE).

    Dmitry Sotnikov, chief product and marketing officer for 42Crunch, said support for the Microsoft IDE assumes that developers will run security tests themselves. By integrating its API security testing tool with the Microsoft continuous integration/continuous delivery (CI/CD) platform, it now becomes possible to make testing APIs for security vulnerabilities part of a DevOps process, he said.

    That approach means organizations don’t have to rely on developers to remember to run a security test on their APIs. Instead, security testing of APIs becomes just another gate in the CI/CD process that gets automatically conducted, he noted.

    The company has already integrated its API security testing tool with other CI/CD platforms at the request of individual customers. 42Crunch will be moving to make those integrations commercially available in the months ahead, said Sotnikov.

    As IT organizations have become more adept at thwarting attacks aimed at end users, cybercriminals are now increasingly focusing their efforts on APIs. Akamai, a provider of content delivery networks, recently reported that from December 2017 through November 2019 it observed 85,422,079,109 credential abuse attacks across its customer base. Nearly 20%, or 16,557,875,875, of those attacks were against hostnames that were clearly identified as API endpoints. Many of those attacks involve, for example, unexpected injections of values to a call made to an API, noted Sotnikov.

    The REST API Static Security Testing Tool can locate API contract files in the repository and run more than 200 security checks based on OpenAPI standard requirements, authentication, authorization and data validation. This makes sure that no new or changed API be deployed in production without meeting those standards.

    Issues discovered are also prioritized by impact and each issue is accompanied by a knowledge base article explaining the issue, its severity, exploit scenario and suggested ways to fix it.

    Sotnikov said the REST API Static Security Testing Tool provides a tangible means for DevOps teams to embrace best DevSecOps processes. Too much of what passes for DevSecOps today amounts to little more than attempting to blame developers for cybersecurity issues, he noted, adding organizations that want to embrace DevSecOps in a meaningful way need to put tools into the hands of DevOps teams that enable them to address vulnerabilities once they are discovered and prioritized.

    It’s also critical to provide those tools within the context of existing DevOps processes; otherwise, developers are likely to resist changes to their existing workflow processes, Sotnikov said.

    It remains to be seen how DevOps and cybersecurity teams will meld their respective cultures to drive DevSecOps. It is likely cybersecurity teams will continue to define controls and discover vulnerabilities. However, as DevOps teams continue to make security a natural extension of the quality assurance process associated with building any application, the number of vulnerabilities being discovered after an application is deployed in production should decline steadily.

    — Mike Vizard