Continuous Security – Building Security into your Pipelines

DeveloperSteve Coochin at Safe '21
Sign up for Conffab Pro to watch this and hundreds of other videos for 19.95 a month

2_DeveloperSteve Coochin: Hello, and thank you all for joining my session on continuous security.

Something we do in Australia before beginning presentations is to acknowledge the traditional owners on the lands in which we meet.

So I'd like to begin by paying my acknowledgements and respects to the traditional owners on the lands in which we meet today.

I am presenting from a small town called Narromine, which is in central west New South Wales.

And is the lands of the Wungunja people.

I'd also like to pay my respects and acknowledgements to the indigenous elders past, present and emerging.

So thank you all for joining my session on continuous security, building security into your pipelines.

For those that I haven't met yet, my name is DeveloperSteve and I am one of the senior developer advocates at a company called Snyk.

Coming from a background of development.

I've been coding since the age of eight.

And my developer origin story, as I like to think of it, I've been a tech lead for digital agencies, built many startups, been a CTO multiple times and developer advocate for companies like PayPal Braintree, XERO, Telstra, and IBM.

One of the things I love the most about being an advocate is getting to work close with tech communities, helping educate, learn, and well just geeking out.

It's one of my favorites.

I've been coding for a number of years now.

And as a developer, one of the things I've always loved is building applications that can help people's day-to-day life.

When you think about it as developers, we build apps that can connect people or even help them automate, even just from the small things, like a food delivery app or turning on the lights.

If you think about an iceberg floating in water, it's a bit like your application with your code, being the but just above the surface, available to all the internet.

One of the things I've always been wary of in my developer origin story is what else is being deployed as part of that platform, or library that you're sending through to production.

Indeed.

There's been times where I've had to go back and clean up a deployed app because it's being compromised.

This is why it's important to make sure we help protect the very users that we build our applications for because our users put trust in us and make sure that we're keeping them safe and doing all that we can to keep them safe.

The second part of that iceberg stack is the libraries and platforms which your code will use.

As open source ecosystems have matured over the years, we've seen a growth in the number of libraries, packages, and platforms.

As somebody that loves open source projects this is always great to see.

And one of my favorites things is seeing open source ecosystems, libraries, platforms, communities grow.

This growth speaks not only to the adoption of use by the way, their industry, but also the number of people getting involved to contribute to projects.

With the growth in open source adoption also comes the emergence of vulnerabilities.

Year on year across the ecosystem we see the growth of newly identified vulnerabilities identified by researchers and malicious actors alike.

These vulnerabilities open potential doorways into your iceberg stack, giving malicious actors access to your application or the infrastructure running ... by your surface application.

This also puts into jeopardy our users, the very users that we are looking to protect.

Depending on the ecosystem, we see a number of ways that this can be surfaced.

NPM for example, we see indirect dependencies being the source of more than 80% of the vulnerabilities identified.

This can happen without you realizing and can be let in as simply as an NPM install and package.

I just want to take a second here too to mention that it's always important to remember, to contribute back where you can to a project or a platform that you're using.

Often when a vulnerability or bug is raised on a community project, it takes time for the issue to be identified and a fix to go in place.

These communities are run by passionate contributors who often work on these projects in their spare time, which is why it's important to contribute back where we can.

One way we do that at Snyk is via a free program called Snyk advisor.

This program works with open source projects to help them keep track of their holistic health of their project, from contributors to vulnerabilities.

It also allows for developers to easily do some due diligence on the libraries or platforms before utilizing them in their app.

We also help the NodeJS ecosystem in running the vulnerability disclosure program and a special thank you to any researchers who have contributed to this project already helping keep our users and ecosystem safe.

The third part of the iceberg stack is containers.

One of the things I love about containerization is the elasticity it brings to enabling apps to be built in a containerized local environment.

Then easily deployed spanning clouds and allow allowing for infrastructure to scale as the app is adopted.

Just like we saw with open source vulnerabilities that can be surfaced into apps, containers are also prone to the same vulnerabilities because they are built from the same open source components.

Year on year, the top 10 Docker base images, for example, carry known vulnerabilities with them.

This is where we need to protect our app users to make sure their data and the apps are kept us vulnfree as possible.

Making sure to not only scan container images, but also starting with the most base possible image and only adding the components in you need for your application.

The way I like to think about this is with great containerization comes great responsibility.

The final part of the iceberg I wanted to mention is infrastructure as code.

Infrastructure as code is cloud infrastructure that is being completely abstracted away in the form of code.

Today, we deploy and scale resources as fast as code, and it's incredible the power that the cloud has provided to us.

At the same time, those mistakes we make in infrastructure configuration is the number one cloud vulnerability as identified by the NSA.

For example, this file based configuration, that adds a rule so that only authenticated users can view or create documents, but, and it's a big but with no authorization implemented, which is the case by default with Firebase, everyone can read and write each other's documents.

Sure your users still need a login to be able to do that.

But did you remember to explicitly disable registration?

Let's look at Kubernetes examples.

Here's a partially Kubernetes YAML file that will deploy a pod.

The full file here deploys just fine, but it's missing out on some crucial security hardening that is not turned on by default.

One of the issues with that Kubernetes deployment configuration I had is that the container is running without root user control.

The pod level security context directive has now fixed it, but it has more issues.

Who knows?

I'm not a Kubernetes engineer, I'm just a developer.

That's why we need developer-first security platforms that point out the issues in the form that we as developers understand them.

And that they are showing us how to fix the problem as well.

We no longer need to be security engineers, just developers who are empowered to fix security issues and keep our users safe.

Now let's do a demo.

Let's get hands on with some code.

What we are going to do is set up a code pipeline using AWS code pipeline.

It's important to note here that I'm using free tier well not only under AWS, but I'm also going to connect to Snyk and do a quick scan as well.

Again, I'm using free tier for, well, both of these things.

So here I have some sample code.

This is a NodeJS based sample app from the AWS documentation that we'll deploy to a elastic Beanstalk instance via a code pipeline.

As you can see, this code is public.

So please feel free to try this for yourself.

So what we're going to do is start by setting up our code pipeline.

So I'm going to create pipeline on AWS in the code pipeline pipelines section inside the, the user interface.

Pipeline name-I'm going to call test.

I'm going to use an existing service role because I've already got some that I've prepared earlier.

Some of these steps and I'll point them out as we go through have been predefined beforehand.

So when we get to the Elastic Beanstalk instance, for example, I've already set that up.

Now you can define a few different deployment locations where you can deploy your application.

So I'm not going to go through all those steps as part of this setup, but you can step through those as you want.

And then also connect those into your pipeline as well.

So going to click next.

Source provider.

I'm going to, because we're pulling in from GitHub, I'm going to use GitHub version two, which is the latest GitHub connection version.

Connection I've already prepared.

This is one thing that I've already prepared earlier.

So I'm going to select the one I've already connected to.

Once that finishes scanning, I pull in my, my repository that we wanted to play the code from.

Branch name, I'm going to choose main, which of course is the main branch.

And I'm going to use code pipeline to do the output output artifact formatting Build provider I'm going to use is AWS code builds and project name I've already set up earlier, but you can also create a new project.

So Test App.

I have no environment environment variables to set.

So I'll just leave that.

And the build type is just a single build.

As I said, we're going to be deploying this application to Elastic Beanstalk, but you can quite easily just choose whatever it is that your application is deploying from.

Our application name.

I've already got set.

So I'm just going to use Test App and the environment name I've already as well, in the previous run.

So I'm going to click next, once you review that, which looks pretty good.

I'm going to hit Create Pipeline.

Okay, while we let that build what I'm going to do now-so this just created the deployable code pipeline.

What I'm going to do is do a quick demo using one of our demo vulnerable apps.

So that you can see the vulnerability that we're going to inject in as part of our, as part of our deployment.

So what we're going to do while that code pipeline is building is have a look at a particular vulnerability that we're going to include as part of our source code.

And then watch it get scanned as part of the code pipeline deployed.

So, here we're using the NodeJS Goof App from the Snyk GitHub.

This has 61 known vulnerabilities in it.

The one where after, in particular today, and we're going to have a quick look at what it, how it works is a cross site, scripting vulnerability that's as part of the, in, as part of the MOC package.

As you can see here from the package.json from the application it's, we're using mark 0.3.5, which does carry the vulnerability with it.

So switching to the application, what we can do now is we'll test a non vulnerable input, which will be resurfaced inside the user browser, which is where this vulnerability lights.

So if we have a look at this URL, for example, this markdown URL, as you can see if I put that in there now, like, and if I hover over it, indeed, if I click that, it'll take me to that websute.

Nothing suspicious here, but where this vulnerability lies is with URL encoded character sets as part of the markdown URL input that basically allows a remote attacker to inject some malicious JavaScript into the user's browser.

So here, for example, we have a JavaScript input, which will basically create an alert box if the user clicks a link.

And it gets around the library sanitization by having the object, JavaScript object 'this' as part of the input, along with some URL encoded character sets.

The library's basically not able to send it, detect the need for sensitization, and it allows it to well basically store the input.

So that link now appears in as part of the, the browser load.

And if I click that as an unsuspecting user.

A pop-up box appears saying this alert box is alerting.

And indeed it is.

So what we're going to do now is grab that package.json library, and then we're going to add that to our other source code once we add a security scan as part of that deployment.

Now that that code pipeline has finished deploying we can edit the flow and add some nice gate control in.

So, this is where you would add your code quality check or your code runtime checks.

And as part of the flow steps for the pipeline to make sure everything builds and is deployed correctly.

This is where we're going to add a security check into our flow.

So if I edit this flow, I can add a stage just after source.

I'm going to call it security.

Add an action group in called security.

And that action provider is where I'm going to connect it to do a Snyk scan.

Can choose it from the list.

Input artifacts-we're going to grab the source artifacts, going to connect the platform.

Here I can, once the configuration screen loads, here I can add in the different severity types for vulnerabilities that are detected.

So here I'm going to choose high, and then I'm going to monitor continually monitor the project.

So this is important because as new new deployments happen, you'll be able to continually pick up if there's any vulnerabilities in the code or the open source libraries.

Project group name, I'm going to call Reporting, hit continue.

Once that has been connected, I can then go through and do output artifacts.

I'm just going to call that scanning.

So this will appear in the output reporting.

So then I can hit done.

And then done And save.

Once I release change, that'll trigger a redeployment, which will then start to rebuild and redeploy everything.

Once the code pipeline is finished running, we can then switch over to see if there's any, anything detected as part of the security scan.

If anything of a severity higher than the high setting had been detected, this would have stopped the flow in its tracks.

And well, as it acted as a gate of stopping the deployment from going any further so that someone else could take a further look into it.

Here, we can see the code pipeline, which has just gone through deployment.

And as you can see, nothing was detected as part of the deploy because there was no vulnerabilities found inside the applicant.

It's very basic, NodeJS code demo code straight from the AWS documentation.

So let's change it up a little.

Let's edit the package.json, and now our mark library in that we know it has carries vulnerabilities with it and we should be able to get detected.

So if I edit the package.json, back on the code repo, that'll trigger a new rebuild and a new rescale.

So I'm going to commit these changes.

So we've now added the marked 0.3.5 library as a dependency into the AWS code pipeline sample.

Now we know that there's a cross site scripting vulnerability inside this particular version of the library.

So once that re-triggers it should be able to then detect that as part of the deploy.

. As we can see here that the gate control the security gate control has failed as part of its deployment.

This is intentional because we've added a vulnerable open source library, which we know has a particular vulnerability already in it.

This is a great way to test the security process flow as part of the pipeline deployment to make sure it will identify known vulnerabilities and stop them from being deployed.

If we have a look at the package.json scan, it has indeed indeed picked up a particular version of the marked library, which we do not want as part of our deployment.

From here, we can actually raise a pull request automatically back into the repository to do a, to deploy a fix or delve into the issues and further to see whether our security teams will be well, that they will accept that particular security vulnerability risk.

That was a quick demonstration of setting up security inside a pipeline to create some nice gate control, to be able to detect any issues as part of your ongoing automatic deployments.

But we missed something, a critical part of the iceberg stack, which is now becoming more prone to vulnerabilities.

Local host, or your development environment is now becoming more prone to the same, very same vulnerability.

As a developer, this is something that is becoming more and more aware of.

As we're seeing more instance of this take place.

Recently, Snyk researchers publish some vulnerabilities they identified in the VS Code ecosystem.

One of which allows a remote attacker to gain access to any file on a Mac using a known path traversal exploit via a VScode extension.

This enables a remote attacker to gain access to your Mac's password file.

There's a link on my, from my GitHub, if you want to see for yourself in action, but please do not leave that version of the extension installed.

This demo scares me so much that I actually run OSX inside of the virtual machine.

Finally, some takeaways to wrap up with.

Always be scanning or ABS.

Source code containers and infrastructure.

As technology folks, we need to make sure we protect our end users.

Making sure the infrastructure and apps they using are as secure as we can make them.

I just wanted to quickly mention too, that we've recently launched a global ambassadors program at Snyk to help build out more awareness about keeping apps, our end users, code and infrastructure safe.

If you want to get involved, please check out the link or reach out to me on socials And finally, always remember to use your tech superpowers for good and be excellent to each other.

Thank you very much.

Continuous Security

Building Security into your Pipelines

DeveloperSteve

DeveloperSteve

DeveloperSteve Coochin

  • Senior Developer Advocate Snyk
  • Seasoned: Dev / Ops / CTO / Maker / Geek / Gamer / Speaker / MC / Hackathon Mentor / Judge.

images of DeveloperSteve on stag, with colleagues, with his partner

App Code

Security issues in this code?

exports.admin = function (req, res, next) { 

User.find( {
       username: req.body.username,
       password: req.body.password
    },
    function (err, users) {}
  );

photo of a dog an a werewolf. Dog is labelled 'my code', werewolf is labelled 'libraries my code uses'

Open Source Code

Graph titled "New packages created by ecosystem per year". Shows data for Maven Central, npm, NuGet, PyPI, Rubygems. npm has over 300,000 for 2019

Open Source Code

Graph titled "New vulnerabilities each year by ecosystem". Shows data for PHP Packagist, Maven Central, npm, Golang, PyPI from 2014 to 2018. Shows Maven central over 1500, and nom over 1000 in 2018, and all growing since 2014.

Open Source Code

Graph showing Vulnerabilities from direct versus indirect dependencies in PyPI, PHP Packagist, Maven Central, RubyGems, npm. For PyPI and PHP Packagist the significant majority are direct. For the others the significant majority are indirect.

Meme of Han Solo and the Text "FOSS will always be with you."

Open Source Code

Blog post with the title "Snyk takes on responsibility for Node.js ecosystem vulnerability disclosure program"

Containers

Graph titled "Vulnerabilities in official container images". Shows vulnerabilities in 2018 and 2019 for container images for node, and a number of OSs and databases. Node has by far the most with 642 vulnerabilities in 2019.

source: https://snyk.io/open-source-security

Meme image of two cartoon Spidermen pointing at one another with the text "WITH GREAT CONTAINERISATION COMES GREAT RESPONSIBILITY"

Infrastructure as Code

  • #1 cloud vulnerability is misconfiguration [NSA]
  • Network access, storage, servers - deployed as fast as code

shows icons for AWS CloudFormation, AWS CodePipeline, Amazon S3

Infrastructure as Code

service cloud.firestore {
	match /databases/{database}/documents {
		match /{document=**}/
 			allow read, write: if request.auth != null;
  		}
	}
}

Firebase

Infrastructure as Code

template:
	spec:
		containers:
		  - name: goof
			image: goof:latest
			ports:
			  - containerPort: 3001
			  - containerPort: 9229
			env:
			  - name: DOCKER
				value: "1"

kubernetes

Infrastructure as Code

template:
	spec:
		securityContext:
			runAsNonRoot: true
		containers:
		  - name: goof
			image: goof:latest
			ports:
			  - containerPort: 3001
			  - containerPort: 9229
			env:
			  - name: DOCKER
				value: "1"

Infrastructure as Code

screenshot of Snyk analysing Kubernetes

Lets do a demo!

Animated GIF of a woman sitting at a laptop cracking her knuckles.

We missed something very important

animated GIF of a Patrick Star from Spongebob squarepants weating a cowboy hat saying "YOU FORGOT THE MOST IMPORTANT PART"

DEV ENV

Demo > github.com/developersteve/VSCode-Instant-markdown-vuln

screencast of VS Code

Takeaways

Takeaways

Always Be Scanning

  • Source Code
  • Containers
  • Infrastructure

Snyk Ambassadors Program

Snyk Ambassadors Passionate about application security? Become a Snyk Ambassador and help the development community build securely.

snyk.io/snyk-ambassadors

USE YOUR TECH SUPER POWERS FOR GOOD

silhouette image from Bill & Ted's Excellent Adventure with the quote "Be excellent to each other".

Animated GIF of Winder Woman crossing her wrists and generating electricity overlaid with the text "MY SUPERPOWER IS CODE"

Thank you

Snyk

@developersteve