Facebook Pixel

Modern security tools provide a variety of implementation options including full-function clients, APIs and CI/CD plugins. What is the best option for you? The answer to that depends on your role and how you will use the tools. Are you doing software development, security, or management?

For software developers, integrating security inside their CI/CD tools is the preferred approach because of automation, signal value, and reduced friction.

CI/CD & Automation

Automation is a key benefit that drives adoption of CI/CD toolchains. DevOps, DevSecOps, GitOps, all of these are enabled or enhanced by CI/CD workflow automation. By automating security analysis and policy evaluation inside the CI/CD workflow and triggering it after build, it becomes a natural part of the developer’s workflow. This greatly enhances both efficiency and compliance.

Signal Value

The results from security analysis and policy evaluation send a valuable signal to the developer, indicating which packages or dependencies are vulnerable/compromised before their work on that docker image is complete. You want this as close to the development process as possible. For example, you could implement security in the Kubernetes admission controllers, but then the signal is often presented to the wrong person, operations, at the wrong time. You then rely on signal routing tools like bug tracking or collaboration tools, but they also delay delivery of that signal to the developer. Implementing security upon container check-in brings it closer to the developer, but for immediate feedback while the code is top of mind, running security analysis and policy evaluation at build is ideal.

Reduced Friction

If developers are forced to exit their CI/CD workflow to get results from security and policy analysis you introduce friction to adoption and use. Adoption friction is caused by the need to learn a new tool, most developers don’t want to take time away from their work to learn new tools. There is also friction in using a separate tool. The developer has to switch out of their development tools into a security tool. This causes friction each time. It compounds if there are multiple tools they must use outside of their normal CI/CD workflow. This friction can result in developers forgetting these steps, so compliance drops along with efficiency. Integrating security and policy evaluation right inside the CI/CD platform is the most efficient approach and results in far higher compliance.

Conclusion

For developers, integrating security and policy evaluation as CI/CD plugins is far more efficient and dramatically increase compliance. It also paves the way for secure GitOps, where the GitOps process involves security and policy evaluation. However, the beautiful and highly functional security clients are not wasted. They serve the other roles: security and management. Security people use the full function client to import, create, test and deploy policies, in addition to monitoring compliance and governance. The full-featured client is also ideal for management who can monitor overall security progress as well as using asset management tools which provide visibility into everything about their containerized code. While full-featured clients serve a vital purpose, developers prefer CI/CD plugins because they automate the entire process inside their existing workflows.

Securing a container involves analyzing for a variety of potential risks over a variety of components inside, or associated with, the container. There are two approaches: comprehensive analysis—analyzing for all risks—or assembling a collection of specialty analyzers. Another way of phrasing this decision is whether the whole (comprehensive) is greater than the sum of the parts (specialty tools). This article attempts to answer that question.

What Are We Securing?

Containers are comprised of code, third-party libraries/tools, operating system components and artifacts.  They are combined with infrastructure-as-Code (IaC) when deployed as pods in Kubernetes. All these components must be secured under the premise that you are only as secure as your weakest link.

To fully secure your containers you need to analyze for the following:

Comprehensive vs. Specialty Tools

Companies can choose between a single tool that addresses all of the above, or they can implement a collection of specialty tools. Comparing comprehensive vs. specialty analysis reminds me of the old joke about doctors: generalists vs. specialists. They say that specialists learn more and more about less and less until they know everything about nothing. At the same time, generalists learn less and less about more and more until they know nothing about everything. While amusing this joke is driven by the fact that humans have a scarcity of time so they are forced to choose how they spend their time between generalization and specialization.

In technology time is measured in compute power, which isn’t the constraining factor it is for humans. In the realm of container security, both specialty and comprehensive security tools are leveraging the same data feeds (e.g. feeds of CVEs, malware, IaC risks, etc.). This levels the playing field between the two approaches, meaning that data quality does not favor one approach over another, it is a push. Let’s dig a bit deeper into this question.

Data Synergy - Mo’ Data Mo’ Better

Viewing security risks in a vacuum results in poor risk assessment and resulting prioritization. This is because risk factors can compound or reduce the overall risk assessment. For example, Container A has 3 critical vulnerabilities, while Container B has 10 critical vulnerabilities, which is the highest priority to be remediated? In a vacuum, you would say Container B. However, if I told you that Container A is running in a customer-facing app, in privilege, exposing a public port and with the label UI, while Container B is running in a little-used internal facing app with no ports exposed, you would clearly prioritize Container A. Proper risk assessment and prioritization requires that you blend a variety of risk factors, which can only be done by a comprehensive security analysis tool.

In fact, correlating various potential risks is so critical that companies are taking a holistic approach to tracking and correlating everything about containers in the software development lifecycle (SDLC); this is called asset management. It can be used to define risk prioritization, instantly identify “at risk” containers, explore versioning risks, and much more. Since asset management correlates all risks, you need a way of aggregating all of that risk data in one tool, which is considerably easier with a comprehensive security tool.

Overlapping & Conflicting Data

While the above section addresses data gaps, you can also have too much data that overlaps and conflicts. Because some tools analyze more than one of the issues above, you can get tools finding the same issue, but assigning it different threat levels, resulting in confusion that slows the development process.

Managing multiple policies is also problematic. Security teams shouldn’t have to learn multiple policy engines and maintain multiple policies across those tools, especially when these policies, which may rely on conflicting threat data, can result in conflicting recommendations. It makes compliance a nightmare.

Impact on Speed & Agility

In an age when corporate competitiveness is often driven by rapid evolution of the software used by employees and customers, speed and agility is critical. Security must operate at development speed. If developers are juggling too many security tools, they slow down. If developers are relying on a bug tracking system like Jira and multiple security tools are creating Jira bugs, a developer might have to deal with 10 different Jira bugs for the same container, when a single consolidated bug post would have accelerated the repair and reporting processes.

Conclusions

Comprehensive container security, with its one-stop-shop approach are much easier than specialty tools. The convenience, efficiency, and ease-of-use are far superior. We find analogues to this in many other areas: Walmart/Target superstores, Amazon’s world’s largest inventory, Multi-function gyms, Microsoft Office, GSuite, and many more. In the world of security, we see Prisma Cloud, Snyk, and of course Carbonetes, taking a one-stop-shop approach to security. We believe that consolidation is the future in container security, let us know your thoughts.

Video Overview of Everything-as-Code (6:27 minutes)

Everything-as-Code (EaC) is the future of IT; the benefits are simply overwhelming. EaC is the next logical step of DevOps; the merger of development and operations. Under the DevOps model, developers took responsibility for running their code. EaC gives developers responsibility to define everything, especially the underlying infrastructure that the code runs on. As developers assume responsibility for selecting, provisioning, and configuring infrastructure, they will also increasingly assume responsibility for selecting technology vendors and services. The inevitable adoption of EaC will reshape all companies that develop software, as developers assume responsibility for many traditional IT functions.  The largest disruption, however, will impact traditional technology vendors who have ignored developers in favor of selling to IT. Those companies will fare as well as the dinosaurs did against the massive meteor strike that suddenly altered their climate. If you think this is hyperbole, you won’t once you read this article.

A Brief History of How We Got Here

Everything-as-Code is actually the merging of three major trends that have been building over the last 30-years: virtualization/cloud, shift-left/DevOps, and Kubernetes/microservices.

Virtualization and Cloud: In the late 1990’s IT companies started virtualizing compute. In the early 2000’s they started virtualizing storage and networking. Public clouds hit the scene in 2006 with Amazon AWS. Unlike on-premises clouds, public clouds do not provide physical access to equipment. Virtualization had paved the way for public clouds and admin panels enabled remote management. APIs then took remote management one step further enabling most services to be controlled via code.

CI/CD, Shift-Left, and DevOps: At the same time, the software development pipeline was being automated first with Continuous Integration (CI) tools, then evolving into CI/CD. Companies began to automate software testing/QA and to move it into the CI/CD process. QA was shifting left, becoming the responsibility of developers. Then security shifted left as developers assumed responsibility for addressing code vulnerabilities, policies, secrets analysis, and more. Then developers assumed responsibility for operating their code as more companies adopted the DevOps model.

Kubernetes and Microservices: Kubernetes, which is quickly becoming the application operating system of the future, enabled microservices, further changing the development pipeline. Kubernetes orchestrates microservices: small loosely coupled services that evolve independently of each other. When companies adopt a microservices development model, there are so many moving pieces that automation is required; traditional manual process simply cannot scale.

Everything-as-Code: Virtualization and Cloud, CI/CD, Shift-Left, and DevOps, Kubernetes and Microservices

Everything-as-Code

Everything is shifting-left to developers and Everything-as-Code is the next logical phase of this evolution. The adoption of cloud technologies provided us with APIs to control provisioning and management functions. Development was already subsuming operations (DevOps) and security (DevSecOps). CI/CD provided the backbone for automating many phases of the development lifecycle. Now Kubernetes provides a standard application operating system powering the adoption of microservices.  These trends combine to enable Infrastructure-as-Code (IaC), enabling automated provisioning, configuration and management functions. With this, microservices can define, provision, configure and manage themselves, all automated within CI/CD tools. Pipeline-as-Code, the automation of the software deployment process often called GitOps, is being automated as well. Everything is being shifted left to the realm of developers in the form of Everything-as-Code.

Not that these trends needed additional incentives, but off-shoring and work-from-home (WFH), which are driven by Covid-19, are further accelerating the adoption of microservices because they reduce dependencies between code. This is increasing adoption of EaC.

As developers take on more responsibility, more functions over smaller pieces of code, they are hollowing out many of the functions traditionally handled by IT. Vendor selection and procurement are some of the traditional IT roles that are increasingly handled in code. This has a massive impact on large numbers of IT vendors who have traditionally sold through IT. Many of those functions are now being defined and executed by the development team in the form of EaC. Those technology vendors who cling to their traditional model of selling to IT, will be increasingly disrupted by those that build a relationship with developers.

Benefits: It’s NOT Just About Automation

Obviously, Everything-as-Code enables automation, which improves development speed, scale, and time-to-market. This is very compelling, but it isn’t the only benefit of the everything-as-code (EaC) trend, not by a longshot. Here are some of the additional benefits driving the EaC trend.

Quality: Developers love to copy code that works. Why create something from scratch, when you can leverage all the thought, refinement, and testing that has been applied to an existing piece of code. EaC puts many of the traditional IT functions into code that has already been put to the test. Code reuse is not only faster, it improves both quality and consistency.

Distributed Knowledge: YouTube disrupted education because you no longer had to pay for a second-rate local teacher, you can learn anything from the world’s expert (or best teacher) in a 5-minute video. Code does the same thing, it enables the world’s experts to define the best practices, and then anyone can copy and tweak the resulting code to fit their needs. Reusable code is the ultimate in distributed knowledge.

Distributed Development: EaC codifies (or code-ifies) processes in code that is shared throughout the organization. This facilitates offshoring and work-from-home (WFH) because they all use the same automation code, such as IaC files.

Cost Savings: In addition to the cost savings that derive from automation, there are other cost savings from EaC. Because it facilitates distributed knowledge, companies no longer need an army of highly specialized and expensive IT people with deep knowledge in a narrow field. That knowledge is in the code itself and that code evolves as human knowledge evolves. Companies can reduce their IT staff and budgets. Spoiler alert: If you are an IT company and you sell to these domain experts, prepare to be disrupted by competitors who cater to developers.

Deployment Flexibility: Companies want the ability to shift workloads based on a variety of factors, deployment flexibility. By leveraging EaC technologies, you abstract away the details of the platform and processes. The code can be easily deployed, moved and shared across any infrastructure, whether on-premises, hybrid- or multi-cloud environments, giving companies the ultimate in deployment flexibility.

Improved Security: There are several security advantages that result from EaC. Policy-as-Code (PaC) can be used for fine-grained role-based access controls (RBAC) to reduce risks. Security-as-Code can be used to automate analysis of software risks such as vulnerabilities, dependencies, license types, secrets, versioning issues, malware, infrastructure-as-code, and more. Shameless plug: This is what www.carbonetes.com does. You can also implement a variety of security measures—such as network microsegmentation—via EaC. There are many aspects of Security-as-Code and it is a rapidly evolving field.

Compliance: For compliance to operate at scale and at development speed, particularly in a microservices world, it must be automated. PaC can automate and distribute the company’s security policies. The results from the above-described security analysis can be automatically evaluated against security policies to ensure compliance. Between CI/CD processes, distributed development and microservices, the only way to enforce compliance is by automating it as code.

Governance: EaC creates versioning and changelogs that can be analyzed to identify when things changed, how they changed, and who changed them. This makes governance much faster, easier, and more scalable than it was in the days of manual provisioning.

Conclusions

Everything-as-Code (EaC) is far more than simple automation, it is the foundation of future IT processes. As more and more IT functions move into code, those functions are increasingly shifting left to software developers. With a shift of control, also comes a shift in ownership. Developers are gaining the power to select deployment environments.

IT Vendors: If you sell infrastructure—compute, storage/backup, networking, cloud, etc.—your customer will look less and less like traditional IT and more like the development team. If you don’t have a strategy to build a developer community and ease their interface to your tools via code, then you will be disrupted by a competitor that does. If your sole interface to your customers is via IT, things will get painful.

IT People: Your users have already disintermediated IT to some degree by going to SaaS applications, known as Shadow IT. Some developers may have slapped down a personal credit card and done their own thing on public clouds as well. But you remained in control of vendor selection as the gatekeeper to the company’s infrastructure. This will increasingly move to code. Traditional IT will be disintermediated, but those individuals who embrace EaC will thrive.

Developers: As more and more capabilities shift to code, they shift-left into your realm. If you develop your skills in EaC, you can lead your company through this transition. A great way to get started is via Kubernetes, Carbonetes and GitOps (IaC + automation agents). If you embrace these technologies, you’ll be calling the shots going forward.

Everything-as-Code will continue to demonstrate faster time-to-market, agility, code quality, security, deployment flexibility, compliance and governance, while lowering costs. This is a wave that will only grow and subsume more of the traditional IT functions. Don’t fight the wave, ride the wave.

Provides Full Suite of Container Analyzers to Secure DevOps/GitOps Inside Your Preferred CI/CD Tool

Houston, TX, May 06, 2021 — Carbonetes delivers all of the security tools developers need to analyze the security of their containers in a single unified service. Backed by a unified policy engine and remediation recommendations, Carbonetes accelerates development, while ensuring policy compliance.
Centralized software development is a thing of the past. Kubernetes and containers have enabled microservices that evolve independent of each other at high velocity. Offshoring, Covid-19, and remote collaboration tools have accelerated this trend. Security has not kept pace with these trends. Distributed and independent development cycles have made security compliance a nightmare.
Until now, assembling a complete container security solution meant acquiring, learning, and maintaining a disparate collection of independent security tools. Some security vendors have responded with a conglomeration of tools that remind users of Frankenstein, with an odd assemblage of incongruous parts that are sure to scare the villagers. Carbonetes solves these challenges with a single unified service that addresses all your shift-left container security needs.
Carbonetes wins the hearts and minds of developers by helping them identify and resolve all container security issues faster. Instead of the traditional trade-off between code security and development efficiency, Carbonetes delivers both. “Carbonetes provides one-click analysis of all aspects of your containerized code, then evaluates those results against your security policy,” said Mike Hogan, Founder & CEO of Carbonetes, “you no longer have to piece together expensive on-premise security applications and multiple policies; Carbonetes does it all.”

Carbonetes Container Analyzers:

While developers love a single integrated security solution, they really don’t want to learn yet another tool, even one as elegant and efficient as Carbonetes. The company addresses this demand by delivering the full developer experience inside leading CI/CD tools such as Jenkins, TeamCity, CloudBees, Azure Pipelines, Drone, CircleCI, Bitbucket Pipelines, and GitLab Pipelines. Carbonetes also appeals to security professionals with a full-spectrum policy engine designed for distributed compliance. Security teams can define, test, tune, and enforce their security policies, or industry standard policies like CIS and NIST, uniformly across all the above analyzers. Carbonetes fits squarely in the realm of developer-centric shift-left container security. However, we are not oblivious to the industry trend of blending developer security and run-time security. Whether you practice GitOps, DevOps, or DevSecOps, there is a recognition that run-time and build-time fit together like chocolate and peanut butter. While IaC is one area of integration, shift-left tools gain considerable insight from run-time usage patterns when prioritizing threat levels. Run-time tools also benefit from continuous scanning to protect against stale images, outdated policies, and new vulnerabilities. The company is already addressing this challenge with run-time integrations like its plug-in for Mirantis Lens. By combining Lens and Carbonetes, your operations team gains visibility into the security of their containers in production, ensuring end-to-end security.
"We built Lens as a Kubernetes IDE - the one place that developers and platform engineers can access everything they need to be successful building and running cloud-native applications. With this new addition to our rapidly growing library of extensions, Lens puts the power of Carbonetes at the fingertips of developers and platform engineers, at the exact moment they need it and without interrupting their workflow," said Miska Kaipiainen, Senior Director of Engineering, Mirantis. By now, you are surely asking yourself: “This sounds amazing, how can I start using Carbonetes right now?” Carbonetes is available through AWS Marketplace and it offers a 30-day free trial. After the free trial, the service costs $40 per developer on the monthly plan and $32 on the annual plan.

Carbonetes delivers answers to some of the most concerning questions:

They say that a person is judged on the company they keep. Carbonetes’ advisory board is stacked with security industry visionaries including, Mike Viscuso (VC, Founder & former CTO of Carbon Black), Tom Barsi (VP Business Development Palo Alto Networks), Anthony Bettini (CTO White Hat Security, Tech Editor of Hacking Exposed), Jeremy Carlson (OEM Sales Kaspersky), and Brendan Hogan (Strategy & Business Development VMWare).

About Carbonetes:

Carbonetes was founded to solve the shift-left security challenges in a microservices world. If you want faster development, distributed security compliance, and the development and security teams to not only be on speaking terms, but to be friends, then Carbonetes is for you. Try it for free at https://aws.amazon.com/marketplace/pp/B08C6P4PFZ.

 chevron-down