Month: January 2020

Anchore: 2020 and Beyond

Posted on by Said Ziouani

Today marks a major milestone in the Anchore journey.

Just a little over 3 years since we opened our doors, we have secured a substantial $20M round of funding that will allow us to address the next wave of container users around the world. I am utterly pleased and totally blown away by what a team of a little less than 20 has achieved in such a short period of time. Like I experienced in the early days of Ansible, just a thousand lines of code and few pages of documentation – built to address an existing gap in the market by smart, capable engineers – can drive ubiquitous adoption in a very short period of time.

While building the Ansible brand a few years back, I had an opportunity to speak to customers and partners and see how containers, and Kubernetes, were transforming the way companies innovate. I quickly became convinced that the next generation compute platform would heavily leverage containers, and security would become key. Today, Gartner predicts that more than 75% of global companies will deploy containers in some capacity by 2022, and the total addressable market is estimated to be $2.1B by the year 2024 by MarketsandMarkets.

Dan Nurmi, Anchore co-founder, and I knew there was a tremendous opportunity. Needing to better understand the security and compliance needs around containers, we decided to build a SaaS platform to test our assumptions. Thousands of users quickly adopted the platform, providing us critical directional feedback on the challenges users and organizations were facing. We have since used that experience to deliver what is now called Anchore Enterprise, our flagship product that is currently in use at large scale by many Fortune 1000 companies including Cisco and eBay, and is even considered a mandatory part of the United States Department of Defense DevSecOps reference architecture.

Anchore’s mission is to empower developers to secure their container workflows in a manner that does not disrupt, distract or encumber them, allowing them to innovate at their own pace. Until now, software workload security has largely been addressed at runtime, but more and more we’re seeing that the majority of issues can be caught more easily during the software development lifecycle. That’s why we want to help organizations shift security left, ensuring that issues are found earlier through seamless integration with all major CICD platforms – whether deployed on-premises, in the public cloud, or through integration with GitHub Actions.

But Anchore is more than just the technology we build. An internal company mandate has been to build both our products and our team with the same core principles that guided Ansible: kindness and accountability. Our goal was never to get from A to B in the shortest possible time; instead, to allow our longer-term vision to be realized while truly enjoying the journey of working with others. I am, once again, thrilled by the fact that those same principles led to another great outcome.

Finally, in the journey to build a global brand, we’ve embarked on hiring great talent with strong open source and enterprise IT expertise. Our office locations already span both coasts, with team members in many US states and soon Europe. We are a fairly distributed team and we’re expecting aggressive growth in the many months to come.

A Buyers’ Guide to DevSecOps

Posted on by Neil Levine

Echoing Dickens, for many in software security, it is the best of times and it is the worst of times. Every day brings literal front page news about software compromises resulting in massive data leaks. Meanwhile, the use of cloud-native technologies has meant that the variety and complexity of the software being deployed has outstripped the ability of traditional security processes and tools to protect their organizations. Security is no longer an afterthought of the IT department but a board-level issue that can cost people their jobs when failures happen.

The security domain is finding answers to these challenges with new practices like DevSecOps and “Shift Left” strategies. These responses address the challenges in the security domain in a similar way to how software developers addressed their velocity and scale issues: by focusing on people and processes. As a cultural practice, DevSecOps is about breaking down barriers between developers, product security, and operations teams so security becomes a shared responsibility and is factored into all parts of the software lifecycle. Meanwhile, Shift Left is a posture that believes better security outcomes are achieved by being proactive in the development phase and enforcing best practices as early as possible.

While recognizing that the ultimate challenges are often cultural and social, software tools and products can help drive change. But for the owner of the security budget, evaluating tools can be difficult, especially where traditionally the security team has only been called in post-hoc to the development of software or the operation of the platform.

What follows are five key new areas to consider when looking at tools for DevSecOps.

Process Flexibility

Not only are we in the early days of perfecting new security processes but many companies are still adjusting to using CI/CD tools or GitOps-based workflows. It is a safe bet to say that every year, there is some change to how your company does software development as you learn what does and doesn’t work for you. When choosing a security tool, it should have the flexibility to integrate with whatever tools you use to drive automation and be able to work in multiple stages of the software development lifecycle. Look for products with full API coverage and an automation-centric architecture. The GUI is important but it should only be something you interact with for ad-hoc or post-hoc reasons. It’s more important that you can push information into the system and get data out using a variety of tools or custom scripts.

Signal to Noise

The ultimate goal is to avoid slowing down development velocity while ensuring developers take responsibility for security. This means they can’t be distracted with excessive data or false positive security alerts. Every security tool can generate a long list of issues for almost every software library or container and indeed this has been one of the calling cards of more traditional legacy tools: the more results, the better. You should verify that there is a way to separate the signal from the noise and that developers can get immediate and useful information to help them resolve issues or make updates as efficiently as possible. Following on from process flexibility, you also need to ensure that that information can get to the developers as part of their normal workflow; security issues are just another type of bug and creating separate security-specific workflows will add friction.

Software Bill of Materials (SBOM)

Supply chain security has become a top issue as a result of the increasing use of open source components and the well-publicized compromises found in various projects. With developers now making the decision about what code to use or re-use and releases often happening multiple times a day, periodic audits don’t work anymore. A Shift Left approach requires that a complete inventory of every piece of code has to be maintained in real-time. This allows ongoing scanning to be performed so the impact of CVEs can be assessed instantly and doesn’t require a crawl of deployed applications.

Data-driven Anomaly Detection

When it comes to runtime, the environment has changed to zero-trust models and immutability as a line of defense but the security techniques are the same: look for anomalies and alert. Agent-based approaches make much less sense in the cloud where containers may not even make running them possible. This is pushing detection to a data-based approach where algorithms can spot anomalies more effectively than admins looking for odd peaks or troughs in telemetry data. As algorithms are only as effective as the data they are applied, tools that collect data from both the platform and the application layer are critical.

Policy as Code

For many, a security policy is captured in Word documents and applied variably with product security teams acting as enforcers through spot checks and annoying requests for reports. DevSecOps evangelizes for repeatability, velocity and automation so in other words: no spreadsheets! It’s critical that policy can be codified and enforced consistently throughout the SDLC in a way that evolves as the threats change. Modern security products treat policy as something akin to another QA test that has to be passed. In this way, policy becomes just another software artifact to be developed, versioned and shipped. Out of the box policies can help you create a solid baseline but flexible policy options are critical for any organization that wants to manage the trade-off between shipping velocity and good-enough security.

Many of the traditional criteria still apply when choosing a security product: choose a vendor that understands your challenges; look for platform agnosticism and avoid lock-in; and select usability over complexity. But understanding that new challenges require new approaches will help you navigate a growing and complex ecosystem.