Code that Writes Code? With Code Robots from Atomist and Snyk, The Future is Now

We’ve all read about a future where software can write software. However, these “code robots,” as I like to call them, aren’t the stuff of science fiction. They are here now, and they can solve real problems for enterprises.

Two companies are pioneers in this area: Snyk and Atomist. Each firm has created a new breed of software that creates code that previously only humans could. In fact, Snyk and Atomist replicate certain human movements and functions. In the case of Snyk, the software performs the task of an infosec specialist. For Atomist, the role is an application architect.

Snyk makes your apps more secure. It scans your code and finds CVEs as well as non-CVE vulnerabilities. But this tool goes further than the handy scanners you know and love. Snyk applies the fixes to these vulnerabilities automatically. Discovery and remediation are done for you.

Atomist provides software development speed. It makes sure that new projects have built-in best practices and collaboration tooling.

When used together, Snyk and Atomist increase stability by finding and applying fixes across groups of apps. Snyk helps the platform team scale good InfoSec hygiene. It monitors code repositories and runtime containers for CVEs and non-CVEs. Atomist can broadcast pull requests for the vulnerabilities that Snyk cannot auto-fix. Run Snyk and Atomist side-by-side, and these services will apply code best practices that eliminate technical debt.

After spending many hours with Snyk and Atomist, I believe these products are part of a new technology trend. Both have Node engines that do things on behalf of enterprise engineering teams. Snyk and Atomist have event-aware back-ends that have integration hooks to web browsers, Slack, GitHub, and Jenkins. And Snyk and Atomist work well with Pivotal Cloud Foundry.

Both tools can be misunderstood by IT because we compare them to legacy products. Roomba by iRobot cleans your floors, but it is not an upright vacuum cleaner. Atomist and Snyk belong to a new product segment. They are code robots.

Watching a Snyk and Atomist code robot talk to each other was the “Aha!” moment for me.

If your incumbent security tool is a compliance report or a brute force gatekeeper, then it is holding you back from achieving better business outcomes.

Snyk in a Nutshell

I am often asked, “Why Snyk?” It’s a reasonable question. After all, there are many security scanners and reporting tools. And conventional wisdom states that security tools should be designed for use by IT compliance and infosec.

But Snyk is different. It treats developers and platform operators as first-class citizens. The product supports the “shift left” notion of security. With this philosophy, security is built in early in the software development process, rather than after the fact.

Snyk excels at vulnerability detection flagging both CVEs and non-CVEs, fix guidance, and vulnerability analytics. What’s more, Snyk does not simply leverage existing vulnerability databases. The company employs security experts that identify new vulnerabilities. Snyk experts craft detailed fix descriptions. Snyk initiated pull requests send the code fixes directly to your repo and the CLI can even auto-patch many Node issues.

Snyk works on a developer’s workstation for ad-hoc testing. It can also run in a CI/CD pipeline. There is a dashboard for tracking issues over time. Sure, any vulnerability scanner can identify and report on CVEs. But these other tools won’t:

1. Find vulnerabilities in your enterprise apps.

2. Auto Fix vulnerabilities in Java, Node, Ruby (more to come) code.

3. Monitor at source code check-in, on deployment, and post-deployment.

4. Prevent vulnerabilities by failing pull requests or deployments that have CVEs.

5. Alert on vulnerabilities via the web, Slack, and GitHub.

6. Engage dev teams successfully and raise visibility to this concern and security as a whole

Atomist in a Nutshell

Atomist is good at three things. First, Atomist can create a project based on existing “seeds.” According to the Atomist docs, a seed is:

Seeds make it easy for new teams to start development without defining baseline dependencies and code patterns. It creates a Slack channel, sets up source control, and configures the build system. 

Second, Atomist can apply “code transformations” at scale. It can use code fix guidance from Snyk to upgrade old Spring Boot projects. For example, let’s say you have hundreds of projects using Spring Boot 1.5.15. This version of Spring Boot is old and has High-severity-level CVEs. Upgrading to Spring Boot 2.1.1 is an easy fix, but it requires testing. This upgrade has a cascading effect on dependencies. Upgrading an XML file setting is easy to do with sed, but sed will not:

1. Traverse an entire GitHub org of repositories.

2. Create a branch to apply the code change.

3. Submit a GitHub pull request.

4. Send a pull request Slack notification/prompt to the dev team.

5. Attach a “Raise PR” button in Slack so the dev team can accept the pull request.

6. Run regression tests and output results in Slack.

Steps 1-6 are the domain of a code robot. The robot repeats steps 2-6 for each project in the GitHub org. Atomist effectively scales the App Architect function. Furthermore, Atomist can help with transforms that are more complex than you can do with sed.

Third, Atomist is a continuous delivery tool. Many people consider this a superfluous feature because CI/CD is a crowded space. But many people confuse continuous deployment with continuous delivery. For continuous deployment, every change that passes the automated tests is deployed to production, automatically. Achieving continuous deployment involves replacing the human workflows that happen after continuous delivery to QA/UAT with automation.

There are two reasons why it makes sense to use Atomist with your CI/CD tool of choice. First, the stockpile of YAML and BASH scripts that live in our pipelines are brittle snowflakes. Atomist makes it easier to create re-usable automations. Second, kubectl is more declarative than cf push. If you are using Kubernetes, it makes sense to put best practice guardrails on kubectl. You can configure Atomist to deploy in a namespace-scoped mode. This pins deployments to a single cluster namespace. Atomist's take on continuous delivery is different from other tools in that it is event-driven. Deployment is just one kind of event. Atomist can react to any event and set goals that can subsequently be completed. Atomist provides a dynamic pipeline that is computed after deployment.

All that said, let’s jump into a working example.

Snyk and Atomist – Better Together

How can you test-drive these code robots? Here is a reference use case:

1. Snyk detects a Java vulnerability that it cannot auto-fix. But it does provide detailed remediation advice.

2. An architect creates an Atomist based code fix.

3. Atomist applies the code fix and submits a pull request on all impacted projects.

4. Lead developer reviews and accepts the architect’s code fix.

5. Snyk reviews the code fix and informs developers and operators of remaining vulnerabilities.

If you want to see this use case in action, watch this six-minute video:

Once you master the basics, you can get more advanced. Configure Atomist to ask Snyk for permission to deploy. A human can watch that exchange happen in Slack. A DevOps team can run GraphQL queries against Atomist to report on deployments that have failed or passed Snyk inspections. Then, your InfoSec team can view vulnerability analytics for each development team.

To learn more about code robots, go to snyk.io and sign up for a free account. Then, go to atomist.com and run the SDM (software delivery machine) "Get Started" guide. If you have a Pivotal Web Services account, you can have your own code robot “Aha!” moment by exploring the code-robots demo code.