Come learn about how we can leverage the agility of modern CI/CD to enhance security! | Register Now
  • What is security DNA?

      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.

  • How does ShiftLeft identify vulnerabilities?

      Rather than leveraging a known vulnerability list such as CVE, ShiftLeft identifies vulnerabilities using modern code analysis techniques.

  • How does ShiftLeft know what data is sensitive?

      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.

  • What is the underlying technology behind security DNA and runtime protection?

      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.

  • What data is going out of an organization’s premises to ShiftLeft cloud and how is that data protected?

      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.

  • How quickly can I get ShiftLeft up and running?

      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.

  • What languages and environments does ShiftLeft support?

      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. Please watch our Product section (link to “Product” page) for updates. To provide us with your input on how to prioritize support for other languages, Click here.

  • What is the ShiftLeft Microagent?

      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.

  • What are the requirements for the ShiftLeft Microagent and how does it communicate with the ShiftLeft platform?

    • Memory: The agent runs in-memory within the application execution environment. The memory footprint is minimal (50MB at most).
    • Communication: A user does not have to open a firewall connection except to the port on which will communicate to the local ShiftLeft proxy, that which in-turn sends data to the ShiftLeft service.
    • Network Bandwidth: The agent communicates with the ShiftLeft platform through the proxy that aggregates batches of events or data before sending it to the ShiftLeft cloud so there is minimal impact on the network traffic or bandwidth.
  • Is the ShiftLeft Microagent compatible with containers like Docker?

      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.

  • Is the ShiftLeft Microagent compatible with application performance monitoring (APM) agents like New Relic and AppDynamics?

      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.

  • What is the performance impact of the ShiftLeft Microagent?

      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.

  • Can a user configure alerting?

      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.

  • Can ShiftLeft understand the flow of tainted data?

      Yes, ShiftLeft understands the flow of tainted data. In a data flow semantic, there are two modes of operation:

    • If someone exploits a certain path, they can read more than what they are supposed to, and
    • If someone exploits a path, they can create an unauthorized sink and then begin to channel the data on that unauthorized sink.
    • 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.

  • Does ShiftLeft change application code?

      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. .

  • How secure is ShiftLeft Microagent?

      It only sends metrics; it does not send any sensitive data out.

  • How is ShiftLeft different from a Runtime Application Self-Protection (RASP)?

      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:

      1. Deployment overhead: Unlike typical RASP tools, ShiftLeft does not require running it in a QA environment before it can be effective. ShiftLeft is informed solely by the source code of the application. Also, because the ShiftLeft Microgent is lean in design and the instrumentation points are precise, the deployment overhead for ShiftLeft is much lower than RASP.
      2. Performance impact: Compared to RASP, ShiftLeft reduces the points of instrumentation by performing targeted runtime analysis that is informed by the Security DNA of the application, which is derived during code analysis. This allows us to keep performance impact to a minimum. Please look at the above Question (What is the performance impact of the ShiftLeft Microagent?) for more details.
      3. Conflict with existing application performance monitoring (APM) instrumentation:RASP tools often conflict with other agents. ShiftLeft’s approach allows for precise control over instrumentation. We pre-emptively observe whether other instrumentation agents are running and can work in tandem with them without disturbing them.
  • How is ShiftLeft different from a Web Application Firewall (WAF) or a next-generation WAF?

      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:

      1. WAF protects web applications against known web-based attacks while ShiftLeft adapts to any class of application and protects against attacks and unknown vulnerabilities, including the use of vulnerable dependencies and leakage of sensitive data.
      2. WAF runs outside of the application between an external network firewall and the actual web application to be protected. ShiftLeft microagent runs inside the application. Unlike WAF, a pattern based system of protection without the context of the application, ShiftLeft has complete application flow visibility because it runs inside the application. This makes the ShiftLeft approach highly performant and precise, resulting in minimal false positives.
      3. WAF does not have per-release visibility that ShiftLeft has, thus requiring special tuning as new versions of applications are released. For ShiftLeft, such auto-tuning of “what to protect against” is built-in, as ShiftLeft extracts the Security DNA of the application for every release.
  • Does the ShiftLeft Microagent conflict with other agent (s) that is running on the same application?

      ShiftLeft observes pre-emptively whether other instrumentation agents are running and can work in tandem with them without any conflict.

  • Do you have an on-premises solution?

      For now, ShiftLeft is only offered as a service. We plan to provide an on-premises solution in a future release.