Editor's note: This article was originally published on Writing by Ryan, the personal blog of Deepfence's Head of Strategic Solutions. We've crossposted Ryan's blog here to share with the Deepfence community.
Recently I decided to leave my previous job of 5 years and take a new position as the Head of Strategic Solutions at Deepfence. I will be responsible for helping lead and scale their solution engineering and customer success functions and work closely with the ThreatMapper and ThreatStryker product communities to build the features the community is asking for. I am excited for all the usual reasons someone is joining a new company: the team was impressive, the technology and what we are selling inspired me, there was a culture fit, etc. But beyond being excited about having what I hope will be a positive operational impact in that role and on the culture of Deepfence, there were 3 specific reasons why I chose to join Deepfence that I would like to explore in this blog post.
The first of the reasons why I was excited was because it was a chance to work on open source software again and help define what the future of open source software in cybersecurity looks like. Secondly, Deepfence's motto "shift left, but secure right" truly fits the operational realities most DevOps and IT teams experience running scalable software and applications in production, while trying to keep them secure and compliant. Deepfence's technology helps bridge the gap between these operational realities and achieving security and compliance for workloads in production. And lastly, because my role will allow me to work with the top enterprises in the best ways to implement and operationalize Deepfence so they can scale their security to meet the complexity of today's multi-cloud infrastructure. This means that I will be at the ground floor with our customers as we work together to defend the world's data against malicious threats and will be able to stay at the forefront of what the market is experiencing today.
I love this quote about the importance of open source software from BigCommerce's eCommerce answers forum, "Open source licensing encourages innovation through collaboration. Without it, many of the technologies we take for granted today would never have developed, or would be locked away behind patent law. The open source movement is the reason that technology has developed at such a breakneck pace for the past few decades." Open source software has left an indelible impact on my personal life and my career. Whether it has been running Linux as a dual operating system on my computers, browsing on Mozilla Firefox, using VLC media player to play media I torrented as a teenager, or interacting with open source software such as Apache web servers or jQuery as the teams I work with build out applications, my interactions with open source software have been plentiful.
More recently in my career, as I have dove back into security more heavily, open source tools such as Security Monkey, Open CSPM, Kali Linux, Metasploit, Nmap, OpenVAS, and OSSEC have been some of the many names that have floated by my desk. All of these technologies have had a few core principles in common: 1) the software and the solution to the problem they are solving are better left in the domain of the public for the common good; 2) the best innovation comes from your community and your community is a foundational element of your product; 3) an enterprise's commercial interest should not reside in commoditized technology or even taking that a step further like in the case of Tesla where they open sourced proprietary, non-commoditized battery technology to push an entire industry forward in such a way that galvanizes that innovation necessary to solve our world's messiest problems.
Deepfence shares these principles, which excites me, and the founders presented me with an even bigger vision of what this means for the future of open source software in security, which hooked me on wanting to come help build that future.
Deepfence truly believes and I concur that basic observability, asset management, and vulnerability management is a technology that should be open source for the greater good of the security and compliance communities but also for the general corporate environment to have better risk postures and operational security postures within their businesses. From the corporate perspective, the first line of defense is always going to be knowing what you even have to protect, which is an increasingly complex challenge when it comes to today's hybrid and multi-cloud infrastructure where developers have adopted a variety of SaaS, PaaS, and IaaS infrastructure that enterprise security teams are now responsible for protecting.
The second line of defense is going to be knowing what state of risk you have across that corporate infrastructure you are responsible for protecting. This is where your traditional vulnerability scanning and management tools come in. This is a technology that has been a commodity for years now and it is a shame that companies are still being asked to pay to know their asset topology and risk profile for those assets. That is why Deepfence has open sourced a tool called ThreatMapper that contains all of these features for free in a sensor that can be deployed across a companies on-prem, private, and/or public cloud environments.
However, Deepfence innovated a step further with this technology and said if we are not giving IT and DevOps teams the information they need to make this asset and vulnerability data actionable, than we are not doing as much to solve the problem as we think because many of the challenges of today's IT security teams are operational in nature (not enough resources - people or money, talent without the skillsets necessary to operate tools, environment sprawl which demands prioritization from a time perspective, etc). Deepfence's tool uses runtime data to show you which of those vulnerabilities you should prioritize from a risk perspective because it is on a more vulnerable attack path a threat actor might use due to the network and application architecture. For example, two assets in your environment might have the same vulnerability on them; we'll take log4j as an example. With most tools you would see this is a critical vulnerability with a high CVSS score that needs to be patched immediately. With 2 servers this may be manageable but when you have hundreds with that same vulnerability, vulnerability management quickly becomes a Sisyphean task. Therefore, knowing that one server is exposed to the internet versus another that is air-gapped will help teams identify which server is most vulnerable to exploit and correspondingly patch because it is part of an exposed attack path or an attack path that is most used by the threat actors. This actionable intelligence that can only be delivered with runtime context makes the Sisyphean task of vulnerability management manageable as it allows teams to prioritize fixing the vulnerabilities that matter most from a risk perspective within the environment.
I could go on about asset features such as SBOM or secret scanning (we will save that for a different post) but the fact that Deepfence wanted to support security for the public good by releasing open source software was more than enough to get me excited about the opportunity to come work for them. However, they went further when they painted for me a vision of the future of open source software in security and Deepfence's role in it. They started naming examples of software that could be built for everyday security problems across the entire MITRE ATT&CK framework and cybersecurity kill-chain. They asked the question of, "what if we could help modern security teams who are adopting cloud technologies solve operational problems at each stage of these attack and defense frameworks by releasing open source tools for operators to use to secure their enterprise networks?" They asked, "what if we could be the HashiCorp of security?"
This resonated deeply with me as for too long companies have kept commodified security technologies proprietary and commercialized in such a way that presents major budgetary concerns for enterprises trying to build out a suite of tools to protect their enterprise. Commodity tools should be released to the public open source, not only to alleviate these cost pressures on businesses but to level the playing field for all security professionals fighting threat actors today. A rising tide lifts all ships as they say, and heightening the security posture of all companies heightens are collective security posture and availability to fight serious attacks. To be able to participate in this vision of helping raise the collective security posture across various attack paths, while giving companies with greater security maturity the opportunity to upgrade into commercialized offerings as they scaled their business made me excited; I am able to help further innovation within the security industry as a whole with the help of the open source community we are building, while building products with true differentiation and value to security professionals looking to better their threat detection and response initiatives in a meaningful way.
If you are an IT professional you are well familiarized with the DevOps lifecycle and the perfect balance between development and operations that DevOps teams were supposed to create. Then you add security into the mix, call it DevSecOps, and this 3-team balance of magical harmony is supposed to come into existence. As we all know though, this is is far from the truth. The operational realities of DevOps and AppSec teams are not well aligned and there is constant tension before all of the automation development teams build into scalable software and the realities of that software running in production for application security teams. And neither side is to blame as they are both attempting to accomplish their individual and team responsibilities.
While the shift and secure-left camp is confident that they can automate the process of scanning and delivering code to production within the CI/CD process, ensuring that code without vulnerabilities is never shipped and deliver this promise with good intentions, there are inevitably limitations to what this approach can accomplish. Ultimately, it becomes unrealistic that all vulnerabilities can be patched prior to deploying to production due to resource constraints. 3rd party resources and components that are part of the application stack may not be subject to 3rd party and resources. Unknown vulnerabilities may be discovered after a component is deployed in production, especially given the high percentage of application stacks that use open source components in their applications.
So what do we do? Abandon all hope and never shift left or scan pre-production code for vulnerabilities? No, of course not! However, the vulnerability scanning technology set is commoditized and we should open it up to all! We can also do our best to marry the intelligence we gather from vulnerability scans about our risk posture with runtime intelligence concerning our application architecture to paint a more cohesive picture for businesses of their most vulnerable attack paths; we can then use this runtime context to more effectively correlate alerts concerning indicators of attack and compromise and respond to these correlated alerts with cloud native protection and response features. This prioritization of threats not only by severity and CVSS but by exploitability in the attack lifecycle can then help DevOps teams decide where to focus their limited resource sets, ensuring maximum risk coverage for the business by impact to the bottom line of protecting sensitive data.
Deepfence has solutions for this cohesive approach by combining its ThreatMapper (open source) and ThreatStryker (enterprise) products. This combination helps bridge the operational gap and tension DevSecOps feels today and it makes me excited to continue to build solutions for those teams. I want to ensure that development teams can effectively ship secure code to production and application teams can make secure and compliant those workloads in production!
And that brings me to my last point, which will also serve as a conclusion to this post. One of the best things about technology for me is the ability to create innovative solutions to problems for customers but at the end of the day those innovations have to work for the practical realities that operators face in their day to day jobs or those innovations are worthless. In the role of Head of Strategic Solutions, I will be on the frontline of talking to customers and hearing their operational challenges that keep them up at night. This will help me stay at the forefront of what these customers truly need to run their businesses in a secure and compliant manner and bring that back to the Deepfence business, working with the product and engineering teams to build open source and commercial solutions to address these problems.
Not only will this help us build software that finds product-market fit and scale our business, but it will help us build software for the greater good of the security community. And while we are building that software, our customer's feedback and working together on solutions will provide a humbling sounding board to keep us honest that our solutions are being built in a way that can be operationalized given the realities of the boots on the ground within the business. And hopefully, we can turn those boots on the ground into the heroes of their teams and businesses with the solutions we come up with together! And that's ultimately the last reason why I am excited and happy to be at Deepfence: it is a chance to build solutions with the community and make other people heroes at their job.
I am incredibly excited and thankful for the team at Deepfence trusting me with this opportunity. I think the future of cloud native security will never be the same! If you would like to learn more about Deepfence, reach out at ryan@deepfence.io with questions. I'd be more than happy to have a conversation!
.png)