devopsy.kinsta.cloud

Tag: security testing tools

  • 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

  • Shifting Left – But How Far Left Do Companies Need to Go?

    Shifting Left – But How Far Left Do Companies Need to Go?

    For developers, there’s nothing more satisfying than looking at a web app or service and being able to say “I made that.” Or at least part of that. Being able to develop code that works and helps millions of people do what they need to get done is an excuse for bragging rights.

    But the opposite is also true. You don’t want to be the developer whose code inadvertently enables hackers to take control of online apps or services, for instance. There are many examples of these kinds of errors. Hackers are better and more sophisticated than ever, and no programmer wants to be the culprit in the ever-increasing number of attacks based on poor coding practices.

    Where and when do errors like these creep in? It could actually be at any stage of development. Vulnerable code could be the basis for a main module in an app, including in the very early stages of development. Once implemented, bad code travels through all stages of development, making apps vulnerable to exploits. Hence the importance of shifting left–deploying security at as early a stage in the process of code creation as possible.

    What exactly does shifting left mean in the context of code development today? Tools need to be integrated in as early in the process of development as possible, and at every stage of the software development life cycle. Today, programmers will work on code and commit their changes several times a day. They need to be able to examine that code for security issues before committing that code to the repository that other teams will be basing their work on. That, of course, is what they would do if they were checking for functional defects, and the same must be done to exclude insecure code.

    What’s the best approach to shifting left in the early stages of development? Developers need tools that can supply them with actionable information, highlighting specific issues in specific lines of code. Sort of like a “spell checker” for security risks, the tools would point out the location and issue in a line of code, and even make recommendations for how to mitigate the risk.

    With that, there are some caveats that come with tools that report risks at such a granular level. Tools should be flexible enough not to over report issues. One general problem with security tools is the possibility of false positives. Security testing tools are notorious for generating very long lists of reported issues, with many of them turning out to be false positives or issues that are not critical to fix. So, to be taken seriously and provide real value, security testing tools need to effectively highlight the high-severity alerts that you cannot ignore and also separate out true vulnerability signals from noise (i.e. false positives).

    Another caveat is that other tools need to be deployed further on in the development process. When a module is completed, it becomes a building block for other modules that will eventually be part of the full program. Testing needs to be done to determine if there are security risks when modules work together. Thus, you should not consider security as shifting left, but rather expanding left, maintaining a presence alongside the development process as it moves forward. With this kind of strategy, programmers can be sure they will have those bragging rights, proudly pointing to what they built.

    — Shahar Sperling