The security DNA of an application describes all of its security-relevant aspects. This includes the execution space of code (the methods that are called), flow and treatment of data (to determine whether sensitive data remains within expected boundaries), dependencies used, and vulnerabilities. ShiftLeft comes with built-in policy that sits on top of the Security DNA to identify potential insecure behavior.
Rather than leveraging a known vulnerability list such as CVE, ShiftLeft identifies vulnerabilities using modern code analysis techniques.
ShiftLeft’s approach is different from the majority of the systems that deem an element sensitive by observing values. During code analysis, ShiftLeft identifies the data elements in code as sensitive based on the variable names as representations of business objects. It then follows the sensitive objects through the application source code by inspecting all data paths. For instance, in a banking application, variable names for customer's bank account information, personal identity information, etc. contain details about business objects that are sensitive. ShiftLeft tags certain data categories as sensitive such as infrastructure keys / passwords, private keys, access tokens, credit card data, and social security numbers. In future releases, customers will be able to define additional data elements specific to their application that should be tagged sensitive.
ShiftLeft creates a scale out code property graph from analyzing your code. The graph is similar to a social network. But, instead of humans connected to humans and exchanging information, the ShiftLeft graph consists of functions in the source code that are connected to each other and exchanging information about data and flow semantics. This graph is an internal construct (not exposed to the user) and is stored in a very secure tenant for the organization, with encryption at rest. Code property graph evolves with code. Security DNA is derived from this graph every time a new version of application is created. Informed by the Security DNA, runtime instrumentation is built in a bespoke manner for each version of your application. The ShiftLeft Microagent uses this configuration to monitor runtime behavior and detect when it deviates from the norm.
Shiftleft integrates with your CI/CD system to collect data in two phases. At build time, the following data is collected: Source/byte code of a version and every revision thereafter, inherent software dependencies (open source or closed source), metadata of a version such as commit-id, commit-user, commit-time. At runtime, the following data is collected: metadata describing the running application, throughput metrics of instrumented methods and data elements, security violations in execution paths, sensitive data leaks on unauthorized output channels or unencrypted data on authorized/unauthorized channels. Although ShiftLeft identifies and tracks uses of sensitive data in your application, the data itself never leaves your environment. Encryption in-transit and at rest is used for all data related to code. Access is limited to a single backend service with authentical and authorization controls.
A free trial is available to evaluate ShiftLeft using the ShiftLeft CLI. For a complete end-to-end experience, download the ShiftLeft CLI and try it with our test application within minutes. Click here to start a free trial and get more info. To ensure that you have the most optimal experience, we are limiting the trial to our test application only. Over the next several weeks, we will be working to make our pipeline robust to onboard other apps. At that time, integration using the Jenkins plugin will also be available as an option for trying ShiftLeft. If you’d like to be notified when we are ready to start accepting custom apps, please fill out the contact form.
ShiftLeft currently supports all applications or microservices written in Java. The microagent is infrastructure agnostic: it can run on virtual machines, containers, unikernels, and bare-metal-any platform that can run the JVM. ShiftLeft will continue to add support for other programming languages on a regular basis. To provide us with your input on how to prioritize support for other languages, Click here.
The ShiftLeft Microagent is a small agent that is instrumented into the JVM. It is informed by the application’s Security DNA thereby only observes specific flows that are deemed of interest (either because they are vulnerable, or dealing with sensitive data, etc.). This results in a more accurate and smaller observation set for the microagent, reducing its computation and memory footprint. In addition, the microagent uses optimizations in storing collected data in-memory which reduces network load while communicating with the ShiftLeft service. In summary, the ShiftLeft Microagent is “micro” because it requires much less memory, network and computation resources than other traditional agents used in application performance monitoring or security solutions which typically insert observation hooks in a blanket manner for all functions or a given set of functions.
Yes. The ShiftLeft Microagent does not run as its own process, and instead executes along with your app in it’s execution environment. So, when you containerize your application, the microagent is embedded in the container.
Yes. We’ve made sure to test our microagent with applications monitored by APM agents. We don’t expect any conflicts with the industry standard APM solutions.
The microagent has minimal performance impact on the application because it is code informed and therefore instrumentation is precise. Compared to some popular APM (Application Performance Management) tools, our performance impact is 1/3rd to 1/10th - this includes CPU overhead, memory overhead, and latency impact.
Yes, a user has the option of choosing the type of notification for each alert. For example: email, notification-only, no alert. A user can also define new alerts to prevent unwanted behavior specific to one’s business needs.
Yes, ShiftLeft understands the flow of tainted data. In a data flow semantic, there are two modes of operation:
ShiftLeft tags and labels data as sensitive using heuristic techniques to follow the data based on these two modes of operation. It also examines the context around the data flow to call out if there is an unauthorized sink that attacker(s) can exploit.
No, ShiftLeft does NOT require changes to application code or usage of any security specific SDK during development. For dynamic languages such as Java, ShiftLeft works at the bytecode level using our unique, targeted instrumentation approach which reduces runtime overhead and false positives. .
RASP does not use the understanding of the application code from build stage to inform behavior of the application at runtime, whereas ShiftLeft’s unique approach of extracting the security DNA from buildtime and correlating it to runtime observations leads to more precise security.
Gartner has highlighted several challenges with RASP, including deployment overhead, performance impact, and conflict with APM tools. ShiftLeft eliminates these challenges:
Securing the perimeter with WAF is a traditional approach to application security. While ShiftLeft can be used in conjunction with WAF, ShiftLeft differs from it in the following manner:
ShiftLeft observes pre-emptively whether other instrumentation agents are running and can work in tandem with them without any conflict.
For now, ShiftLeft is only offered as a service. We plan to provide an on-premises solution in a future release.
Please let us know when you'd like to schedule your trial kickoff call.
We'll be in touch shortly to confirm your Free Trial Kickoff call!