The future is here: Three DevOps future trends in OpenRefactory’s Intelligent Code Repair

Ashish Kakran of Thomvest ventures writes about the emerging DevOps trends in a recent article published in the DevOps blog space.

Ashish identifies several emerging trends in DevOps practices. We, at OpenRefactory, follow the commentaries from the thought leaders and gauge how our Intelligent Code Repair (iCR) solves the pain points. We found that there were three cases where Ashish pointed out a problem in the current practices and iCR could readily solve them.

  1. The abundance of micro-services. For all the existing bug detection tools, micro-services bring a challenge. Suddenly all the context needed to evaluate an application is not available any more. The services interact in a variety of ways. So, trying to connect the dots in a SAST (Static Application Security Testing) tool is an ad hoc process that does not scale. OpenRefactory’s iCR identified the need to understand and process different frameworks as the most fundamental goal for over a year and have a solution that will stitch the services and create better context. What does this mean? Fewer false positives and fewer false negatives, period! On benchmark tests, iCR had only 3% false positive reports (1 false positive in every 33 bugs reported) which is much better than the current industry results which has false positive rates above 50% (1 false positive for every 2 bugs reported).
  2. Shifting left with code. The shift left phenomena promotes that bugs need to be fixed early in the development cycle. This requires giving developers the control of the SAST tools. Traditionally, setting up the SAST tools for work is not the easiest task and is typically left for the IT department. I worked with a senior engineer at a large corporate engineering team trying to setup Fortify, which is used inside its team, to run on a single open source project. It took several days before the setup could be done. Now, imagine this setup overhead incurred by every developer for every project. This simply does not scale! OpenRefactory’s iCR is available on the cloud such that developers can just plug into their project. Within 10 minutes from leasing a machine in a cloud marketplace, a developer is able to start analyzing a project. This is key to allowing developers to use SAST tools as a part of their development cycle and not needing to wait for the IT department.
  3. Building for the Cloud. Cloud infrastructure is an enormous opportunity that Gartner expects to grow to $412 billion by 2024 (reported in the blog post). OpenRefactory’s iCR is currently available in the AWS marketplace  ( and soon in the Azure marketplace as well as being available for on-premise deployment. In its cloud philosophy, OpenRefactory does the following things right.
  • Many bug detection solutions currently offer their solution as SaaS. But why should a developer trust a bug detection tool vendor to provide protection for their code? iCR is available as an Infrastructure as a Service (IaaS), meaning the developer/user retains full control over the machine and has protection that the source code is never shared with OpenRefactory.
  • iCR is available as a pay-as-you-go service. When a developer is not using it, they are not to paying for it.
  • iCR setup overhead is minimal. A developer just instantiates a cloud machine, connects to it with his/her web browser, points it to the source code repository and that’s it! It requires less than 10 minutes. Once a developer has used iCR in the cloud a few times, it will take even less time to be analyzing projects. So, a developer can come back again and again to regularly keep his/her projects scrubbed or to analyze new projects as they are developed.

Recent Posts

SAST Signal to Noise

This is an opinion piece written by Charlie Bedard, COO of OpenRefactory. Charlie reflects on