As we outlined in a previous blog post, if we are to choose ideal technologies for DevOps, they should be the ones that are: 1) invisible to Dev and Ops teams, 2) do not require learning by Dev and Ops, 3) run practically by themselves, without Dev and Ops interference, 4) continuously test applications in increments, 5) not only detect vulnerabilities, but also protect applications against attacks, 6) deliver highly accurate results in real time or with minimal latency.
A couple of technologies have recently emerged to support the above criteria, and some long-existing technologies have begun transforming to support them.
One of the technologies that fully enables DevSecOps is runtime application self-protection (RASP). It addresses the Ops phase of DevOps, which has not been adequately protected by existing technologies. Traditionally, application protection has been addressed by perimeter-based technologies, such as firewalls of different kinds, including web application firewalls (WAFs). Those technologies lack accuracy, as they are traffic inspectors with no insight into application logic flow, data flow and application composition and distribution. On the contrary, RASP is an agent that gets instrumented into an app server and, therefore, has complete insight into the running application and is thus capable of securing the application with high accuracy. Once installed, RASP runs by itself. It practically does not require Dev and Ops professionals’ attention: They do not have to invoke or run it. It does not require any learning on their part. It produces results by protecting applications and by reporting instantaneously and continuously on detected attacks.
A related technology is IAST, which typically is a combination of a RASP agent installed on a test server where developers test their application and an attack inducer that simulates hackers’ attacks. That inducer might be a DAST technology, or a built-in attack simulator, or a Quality-Assurance/User-Acceptance test. The RASP agent is invisible to DevOps teams. The inducer, when it is a built-in one or when a QA/UA test is used, is practically invisible. IAST results are instantaneous: they come from the agent installed in a test server, in closest proximity to DevOps.
Besides these two emerging technologies, some long-existing technologies have begun undergoing a transformation to support DevOps. First is SAST.
A new transformation of SAST is emerging. It can test units of code, individual classes of code and individual files, in a matter of seconds. Developers can invoke such unit tests out of their IDEs by just pressing a button, and get practically instantaneous results back. Results are routed back to a developer, before he/she has committed code to a central repository, and before a project manager or his/her peers see it. Developers will start committing only code that they have tested to a central repository, after security vulnerabilities have been fixed. Security testing will cease to be a “punishment” that reveals mistakes made by individual developers to the team and their manager. It will be a rewarding process that teaches developers secure coding.
Software composition analysis (SCA) will follow SAST, and will be applied for composition analysis of small application increments produced by the DevOps teams. This enables developers to continue to leverage the productivity benefits of open source software while managing the risk of vulnerabilities in those libraries.
“Traditional” SAST and DAST will not go away. They will be used for system tests, just before the major assembly of the application increments is about to be released. These test run infrequently, but are still essential for ensuring risk management compliance and security of the complete application.
These emerging and evolving technologies are creating the backbone for secure DevOps.