Bionic is an application security posture management (ASPM) platform that allows security, DevSecOps, and engineering teams to make their applications and APIs secure in production environments without impacting the speed of software delivery in the cloud.
Bionic addresses a gap in the market for teams to see and secure their application security posture in production as engineering teams continuously deliver code.
Before Bionic, security teams were limited to application security testing (AST) consisting of SAST, DAST, and SCA tools focused on testing source code as developers committed code and performed builds. This shift left concept is beneficial to eliminate security bugs early in the development lifecycle but doesn't test the security or posture of an application once it is deployed in a highly distributed and complex production environment.
In addition, the only tools to provide production visibility for teams are CSPM, CWPP, and CNAPP, which focus on the security of the cloud infrastructure, services, operating systems, processes, and container workloads. Application and APIs remain a black-box which is abstracted by containers or virtual machines (VMs).
Bionic analyses the security posture of your applications, API, and sensitive data flows in production as engineering teams continuously deliver code. This differs from security tools that test source code (e.g., AST, SAST, DAST) or analyze cloud infrastructure (e.g., CSPM, CNAPP).
Bionic is agentless and uses standard APIs to discover, reverse-engineer, and map your application dependencies as they were deployed and configured in production. It's Google Maps for your Apps.
Bionic gives teams a real-time application architecture view of their applications, services, APIs, sensitive data flows, and 3rd party dependencies without analyzing a single network packet or instrumenting your application.
From these insights, Bionic can further analyze and risk score all the attack surfaces and vectors in your applications and APIs using application and business context to ensure only the critical business threats are seen and resolved by teams.
Bionic licenses every unique service or dependency it discovers within your application(s) or environment(s).
For example, if an application had a payment microservice that connects to a 3rd party service like Stripe, and an order database like MongoDB. Bionic would license 3 unique services (payment, stripe, and order) regardless of how many instances of those services exist across environments and/or containers/pods.
For example, if your payment microservice were replicated across 5,000 pods in a Kubernetes cluster, Bionic would only require 1 license, not 5,000.
In addition, if this payment microservice were deployed across three environments: dev, QA, and production, Bionic would only require 1 license, not 3.
Bionic uses an agentless process to integrate through standard APIs and queries your cloud application run-time environments.
When an application environment changes, Bionic analyzes the deployed application binaries (e.g. WAR, DLL, JARs, py/.js files), run-time configuration, manifests, environment variables, and any related config that your applications require to run.
From then, Bionic reverse-engineers these artifacts to provide a complete application architecture map that is code accurate, showing all services, APIs, dependencies, and sensitive data flows. In addition, an software bill of materials (SBOM) is created for each service that details every component, library, framework, and dependency.
Finally, Bionic analyzes and risk scores all application services, attack surfaces, attack vectors, and threats for business-critical risks. Bionic performs this using industry-standard vulnerability databases and integrates with your existing tools to ingest threats you have already detected.
Bionic analysis and baselining time vary depending on the size and complexity of your application environments.
For example, analyzing a simple microservice takes minutes, whereas analyzing a complex monolithic application for the first time could take hours, depending on the size of the binaries.
From customer evaluations, a typical cloud application consisting of a few hundred services normally takes an hour to learn and baseline.
In most cases, Bionic will be owned by a centralized team like DevOps/DevSecOps who is responsible for providing Bionic as a Service to other teams internally (e.g. Security Architecture, EA, App/Product Security, Cloud Architecture, SRE, ..).
Its typical for Security teams to work with DevOps/Engineering to embed tools into their CI/CD pipelines and processes to make sure they are integrated and operational.
First, you need to establish clear ownership of Bionic with a leader from DevOps/DevSecOps or App/Product Security. This owner will be responsible for providing Bionic as a Service internally and be the single point of contact.
Secondly, you need to identify the key teams and stakeholders who will use Bionic. In addition, you need to identify the key workflows and communication channels (e.g. email, slack, pagerduty, JIRA, SNOW) these teams use to share information and action insights. Bionic must be integrated with these tools so it can become part of the customer’s internal processes and workflows.
Lastly, you need to identify the application run-times and clouds that Bionic needs to integrate with in order to analyze applications and become embedded in the various CI/CD pipelines that push application changes. Automating the deployment of Bionic is critical so it can scale with requiring hands-on configuration.
The short answer is both, DevOps generally host/manage the tool, and security teams use the tool for daily operational activities. Bionic has many use cases that span security and DevOps/SRE teams from simple cloud application visibility to impact analysis to application and API security.
The Bionic architecture was built for enterprise security requirements.
Bionic does not need access to any source code repositories like GitHub.
Bionic collects the application artifacts along with their configurations directly from your Clusters, VMs, Containers, and FaaS and reverse engineers what is deployed. The ephemeral scan takes 15-30 seconds and has close to zero performance impact.
Remember, Bionic never looks at a network packet or Application log, so Bionic never sees PII, PCI, or other sensitive or regulated data.
Bionic SaaS runs within an AWS SOC2 compliant environment. Bionic agentless collection process communicates outbound only via TLS to the Bionic Cloud, so no inbound communication is initiated. The customer’s application metadata never leaves this environment, and sensitive parameters are redacted during analysis and not persisted during the reverse engineering process.
If Bionic SaaS is a no-go, then we can provide you with our Bionic on-premises option so you can deploy/manage Bionic in your own data center or cloud environment.
Bionic does not need access to any source code repositories like GitHub. Bionic collects the application artifacts along with their configurations directly from your pre-production or production environments (Clusters, VMs, and Containers) and reverse engineers what is deployed. The ephemeral scan takes 15-30 seconds and has close to zero performance impact.