As an Open Source veteran, Dirk Hohndel, Vice President and Chief Open Source Officer at VMware, is not a happy man when it comes to the state of containers. He has been working on creating awareness about the security and compliance risk containers pose. And now he is witnessing a new and even more disturbing trend.

An inconvenient truth

Docker made it extremely easy to use containers. It helped companies to embark on their cloud-native journeys by simplifying the process of app development, deployment, management, and distribution. Just pull or spin some containers and it’s good to go in production.

One of the side effects of this ‘ease of use’ is that developers are conditioned to not worry about the content of their containers. That’s when a gift becomes a curse.

Next time when you watch a cool tech demo at some cloud-native event, just ask the presenter what open source code is running in their application. You would probably hear that they put some containers together and it worked.

“Developers using cloud-native technologies to build their solutions don’t know what code is running in their own software,” says Hohndel.

He feels that software development in the cloud-native space is slowly moving away from an engineering discipline (where developers have a very deep technical understanding of the code flow of their application) to something that feels much more like a trade where developers simply follow patterns.

A contrast can be drawn with the embedded Linux community where developers care about every byte, every library, and every component of it, “They [embedded Linux developers] have a deep understanding of how the code flows through different components and what is actually running,” says Hohndel.

Embedded systems are essentially monolithic. Does that mean developers of monolithic systems are more attuned with the code than their counterparts dealing with microservice architecture? Not really. The monolithic architecture that’s seen in embedded space is a result of the extreme resource constraints. These systems are designed for optimal utilization of resources. It takes a lot more time to build these systems. Microservice architecture, in comparison, helps developers in creating more complex and powerful applications in a short time, at a much faster rate.

It’s really not about monolith vs microservice. It’s not even about technology. Then why is there such a stark contrast between two architectures? Hohndel believes it’s a social problem.

A review of the past 18 months of security-focused news cycles reflects a pattern. There is a surge of security breaches. Almost every big company – including Google and Equifax – experienced some kind of security breach. It seems like in the rush of moving fast developers don’t have time to take a pause and look at the code they are running? According to Hohndel one of the root causes of these problems is what is assumed to be a reasonable, accepted behavior of doing things in the cloud-native space.

“When you talk to people, you often hear that they didn’t look at all the components they were using,” says Hohndel.

This behavior needs to change. “Maybe we need to take a step back to rethink how we architect our applications,” according to Hohndel, “As you assemble your solution, you should create a practice for each component. Do an architectural review with the red team, with someone who by design is supposed to disagree with you and to challenge your assumptions.”

As engineering teams start arguing about these assumptions, they will automatically go through the details of their architecture. They will start asking questions from those who understand these aspects of their microservice architecture. They will start looking at the code-flow.

“That’s really what I’m looking for. I’m looking for more of this critical engagement with your solution and not just click and drag programming,” says Hohndel.

Conclusion

But not everything is gloomy and dark. All the attention that security breaches are getting is spreading awareness about the topic. Awareness leads to change. Hohndel himself has been one of the drivers of these changes. He talks about it whenever he gets an opportunity.

As a result of this awareness, Hohndel is noticing some positive changes. The Cloud Native Computing Foundation (CNCF) recently announced a new SIG around security which will be conducting reviews of CNCF projects.

“The SIG won’t be doing a line by line code review, but it will look at the code flow. It will look at the architecture and the reasonableness of the assumptions in those projects,” says Hohndel, “To me, that is a great starting point. That’s the kind of initiative I am excited about.”

VMware, the company where Hohndel works, now has a team that is dedicated to making infrastructure more secure in a pure open source fashion. It’s actively working with projects that would help create a safer environment.

There is nothing great about not knowing what’s running in the software. It poses security risks as developers are unaware of the attack surface. It poses compliance risk because developers don’t know whether they are complying with the open source code being shipped with their solutions. It affects performance. They can’t optimize the code they don’t know is running in their products.

No matter how you slice it, “a better understanding of the code that you’re running is always an advantage,” says Hohndel, “People have started to see the tradeoff between getting something quickly versus making sure it’s well engineered. That’s a good start.”