This technical deep dive highlights key capabilities released as part of Twistlock 19.03. To learn more about what’s included with Twistlock 19.03, check out our full release blog post.

Docker and Kubernetes are revolutionary…but they’re not the only way to run your cloud workloads. You may want to leverage the power of services like Azure Container Instances or AWS Fargate to run containers without managing servers. You may want to run functions on AWS Lambda, Google Functions, or even a self-hosted Function-as-a-Service alternatives. You may have legacy or specialized environments that don’t run on Container Runtime Interface platforms. And, yet, across all of these scenarios, you want to be able to monitor and protect your applications and data.

With the 19.03 release of Twistlock, you can extend protection to all of these scenarios using our Runtime Application Self Protection (RASP) Defender. By wrapping the tasks and containers in the Defender or embedding it directly in the code you’re shipping, you can extend your visibility from traditional container workloads to these emerging platforms and paradigms, automating protection for your deployments.

A closer look at RASP Defender

Twistlock Defender is already available for container hosts (whether stand-alone, deployed on Kubernetes and OpenShift, deployed on Swarm, or in other configurations), stand-alone hosts, Lambda Functions (including via Lambda Layers), and for scanning PCF blobstores. Release 19.03 adds the RASP Defender, which can be deployed as a wrapper for a Fargate task, as part of a Dockerfile, or by embedding the Defender manually in the artifacts that you’re shipping.

In this example, we’re using a Dockerfile. We provide an Application ID so that we can easily identify and apply policies to all the instances of this particular application. The Twistlock Console allows me to quickly create a ZIP file containing the updated Dockerfile and the necessary libraries — download those, unzip them, “docker build .”, and I’m on my way to deploying.

Of course, in most cases, you’re going to have a pipeline that is automatically building, testing, packaging, and deploying this code. For automation, the same thing can be accomplished via the twistcli tool, as I’m doing in this Jenkins pipeline:

   stage('Embed RASP Defender') {
        withCredentials([usernamePassword(credentialsId: 'twistlock_creds', passwordVariable: 'TL_PASS', usernameVariable: 'TL_USER')]) {
            sh './twistcli rasp embed --console-host $TL_CONSOLE -address https://$TL_CONSOLE -u $TL_USER -p $TL_PASS --data-folder /twistlock/ --output-file --app-id sample-app Dockerfile'


Of course, embedding Defender isn’t all that I need to do. I also need to define a rule so that Twistlock knows what protections I want to use.

For example, for our Sample-App, we’re going to prevent unexpected processes from running. Since this is a Java-based application, we’re configuring our policy to only allow Java to run. Additionally, the app should only connect to * and we’re going to generate alerts for any traffic outside of that mask.


With the Defender deployed and policy applied, we’re ready to monitor our app and, if something happens, alert on or prevent it according to the applied policy.


This new deployment approach provides Twistlock users with a way to protect applications on PCF PAS, Microsoft ACI, and other on-demand container or CaaS platforms in addition to our existing support for AWS Fargate. RASP Defender, alongside the other enhancements in this release, puts Twistlock in a position to protect your cloud workloads wherever they run.

← Back to All Posts Next Post →