Securing Source to Production with TestifySec’s Cole Kennedy
TestifySec co-founder and CEO Cole Kennedy discusses the gaps in software supply chain security and his experiences implementing software that led to the creation of TestifySec. Cole dives into the necessity of having an “observer” to attest to steps and security measures taken throughout the software development life cycle, and tools utilized in DevOps and DevSecOps workflows. Cole and members of the TestifySec team are presenting during CNCF’s KubeCon + CloudNativeCon 2024 conference in Paris. Connect with Cole and the TestifySec team at one of their KubeCon 2024 sessions (see below) or via TestifySec’s website https://www.testifysec.com.
TestifySec sessions at KubeCon + CloudNativeCon 2024 Paris:ca
– It’s Not Just About SBOMs: Perspectives on Cloud Native Supply Chain Security (panel)
– Operating a Production TUF Repository
– Bee-Lieve in the Metadata: Pollenating Build Attestations on Kubernetes with Tetragon and eBPF
https://colocatedeventseu2024.sched.com/#
Transcript
This is Textron tv. Hey, everybody. I, I, the great pleasure of being joined by Cole Kennedy.
Cole is Co-founder and CEO with Test Testify sec. Welcome, Cole. Good to be chatting with you.
Hey. Hey. Great for, uh, great, uh, to be here.
Thanks for having me on the show. You Bet. You know, we're, we're talking before, right before Coup Con, so folks may see this before, also after.
I'm excited to talk to you about some interesting things going on. But for folks that might not know, testify sec, tell us a little bit about it. Yeah, so we're a somewhat new company really focused on, uh, software supply chain security and Providence.
It, it, it's really about, um, being able to prove the, uh, provenance of your, uh, artifacts, right? Uh, we collect all that metadata about those artifacts and then allow you to validate that things happen the way it's supposed to happen. Fantastic.
You know, as a, as a fellow entrepreneur, we always have the interesting origin story. If you don't mind sharing a little bit, like, why did you step out from whatever you were doing before and say, I've gotta form this company to go do this. Yeah.
So it's, it's a little bit different story for us. Um, I actually, uh, spent 12 years in the military, uh, before I actually got into software engineering, um, more than a hobby. Um, you know, as I got outta the military, I still wanna stay a part of that mission.
Um, so I started working for Joint Special Operations Command, um, and I really found that deploying software applications on some of these classified networks isn't really that easy. Um, and I actually was deployed to, uh, um, um, Jordan to deploy one of our mission applications for, uh, the intelligence community. And this was on a different network than we we normally deploy to.
Um, and so they sent me a week before Christmas. It was really, really important mission, and I get there and we don't have the right compliance package, right? I'm sure we've all run into this before where we don't have a security check or we don't have a scan that we need.
So, you know, our project gets delayed. Well, this was a little different because I was on the other side of the world. It was over Christmas, and my wife and my, my 1-year-old daughter were, we're at home.
Um, so this really kinda gave me the push that I needed to say, Hey, you know, how do we solve this problem? How do we deliver software in, in high compliance environments? So as I moved on with my career, I, I found out that, hey, it's not just the DOD that has this issue, right?
Mm-Hmm. It's, uh, critical infrastructure finserv, right? Anybody that has these compliance concerns, it's really important that, uh, they understand, uh, what happened in their software, and then they can, they can communicate this to the authorizing officials or the CIO who, or whoever's responsible, um, for the risk of that software.
And it's, it's throughout, right? It's, uh, not only government and military, but in the public sector, and everybody's really trying to beef up, you know, their security, their software and their software supply chain tell, well tell, I'd love to get your perspective on kind of state of where things are. You've lived it, right?
Trying to deploy in software in Jordan. Not a great place to get stuck, I assume, over the holiday with your family back here in the States. I'd love to get your perspective on kinda where are we with the, the, uh, adapting or adopting, uh, DevSecOps, but also more importantly, the supply chain security and kind of how we build more attest station as well, security into our supply chain.
Yeah, so I think we're doing pretty good at creating some tools that solve specific problems, but, but really when we talk about, uh, DevSecOps, it's about communication. And I'm gonna back up a little bit, right? Because we, DevOps, it's all about communication, right?
How do we communicate the intent that we have to deploy to these production systems in a very efficient way, right? Email change control boards, uh, those things were kind of inefficient. So we developed APIs, right?
Like Kubernetes, Ansible, Terraform, and, and we've seen the, the realization of those APIs and those technologies over the past five, 10 years has really accelerated the pace on which we can deliver software. So when we think about DevSecOps, right? How, how are we changing that communication paradigm?
How are, uh, security practitioners and developers communicating with each other? Uh, I say, you know, while we have a lot of great tools that communication, it really hasn't improved at all. There's not a unified API that is in widespread use that's allowing, uh, you know, the security events to be transmitted, uh, throughout the enterprise.
Um, so I think, uh, we need to adopt, uh, API that allows us to do this. And, and when we can do that, right, I think we can actually make some advances in connecting these different tools together. So when you, when you say communicating Cole, you're not talking just the email exchanges or, or Slack messages we're doing, you're talking about coupled with our software also, what do we need to communicate about what's, you know, to your point about being in Jordan, what's been done, what security measures have been taken?
Validations, attestations, is that kind of what you're referring to? You're talking about the whole stack of communicating? Yeah, Yeah.
Everything, right? The, the software development lifecycle is, is a huge amount of events, right? You may have something happens in a GRC system like ServiceNow, like a vendor gets onboarded, then a developer gets a, a ticket to write some infrastructure as code, right?
And, and so that, that's another action, right? Then that infrastructure as code gets scanned, that's another event that happens, right? So, so really, you know, whatever the organization governance says they have to do what their policy is.
We gotta make sure that happens, right? Because that's how we manage risk. And right now we're just running those tools and we're not actually validating that, that the process took place.
Interesting. I would imagine that's pretty widespread, at least it seems in my experience, everybody seems to be at that level. I don't say wanna say every everybody, but this is more common than not common.
True. Yeah. And what we found was, you know, I, um, myself, my co-founder and a bunch of members from the community, um, worked on a few years ago, we worked on the CNCF software supply chain best practices.
Mm-Hmm. And then there was a follow up to that, which was the, uh, software factory reference architecture, right? And what we found in those papers is, is a really major component missing in most software delivered lifecycles.
And that is the concept of this observer. And so I'm gonna actually, um, talk about an analogy or to talk about this through an analogy, okay? Now imagine that you have a daughter and that she's getting married and, uh, you know, the most important thing to her on her wedding day is this is this wedding cake.
It's gotta be perfect, right? And she's got very specific instructions about this wedding cake. You know, she's got some bridesmaids with some allergies.
She wants her nana's recipe for cream filling, right? It's gotta be the right, it's gotta be the right, um, uh, ornaments on top, right? So, so you, as the, uh, father of the bride, you go to the baker and you have this very detailed list of requirements on how this cake needs to get made.
Um, so we hand this list over to the baker, and then maybe a couple weeks, a month later, that cake gets delivered to the wedding reception. And now we have to trust that this cake was made the way we expect it to, right? So this means that we have to have trust in that baker.
This is not a zero trust relationship here, right? We're very, we have to have a lot of trust in that baker to make sure that, that this day is not what, uh, uh, not ruined for our daughter. Um, but instead, what happens if we hire someone to watch every single step of that cake being made, right?
A trusted observer to watch, you know, how many times does that baker wash your hands? Is this cake getting made, you know, in Russia, or is this get cake being made in, in Washington dc right? Um, what temperature is the oven set to?
What are those ingredients? Right? That's an S bomb, by the way, like just the, I was gonna say It sounded pretty familiar.
Yeah. Yeah. We, there's a lot of other things that go into it, right?
Um, so you have this person observing all these steps, and after each step, what they do is they write it down on a piece of paper, and then they sign it and they put in an envelope. So now when that cake gets delivered, we can deliver these envelopes along with that cake. And now as a father of the bride, you can open up these envelopes.
As long as you trust that signature on the envelope that came from that trusted observer, you know exactly how this cake was made, right? So now you can have trust in the cake without having trust in the baker. Mm-Hmm.
Right? It's, it is a great analogy. I mean, so, so draw an analog then to kind of steps in the software delivery lifecycle software development lifecycle, and what that observer role looks like, Right?
So there, there's different ways that you can observe those, the, uh, the components of, or software being built, right? You can query an API and get information from that and sign it. Um, you can run a trace on a build process, right?
And record, record that and, and sign that with a, with a machine identity, right? So, so just like the observers is writing down every single step of that cake being made, right? We need to have some sort of observation process writing the steps of, of that software being made.
And, and it needs to be done in a very specific way, right? If we just have random log data, it's really hard to aggregate and correlate. Um, it becomes very difficult.
I think this is what a lot of organizations are doing right now, but if instead, if we use a specification such such as the CNCF in total specification to record this metadata, it really becomes portable and usable across the enterprise. In addition, you can use policy to, um, uh, write policy against these attestations to cryptographically prove that the steps in the supply chain happen, right? So just like that, father, the bride opens that envelope.
We, we have automated controllers that can open envelopes and inspect that attestation data to, to know that, hey, this, this piece of software underwent the steps that our governance documents say they have to go under. Mm-Hmm. Interesting too, when you talk about just having access to the data, the log data, whatever it might be from the tools or the tool chain you're using, that doesn't mean you can assemble all of that into a meaningful way.
Like, yeah, the build succeeded, a scan ran, but what happened? Well, that information happens from a scan tool and a build tool and five other things along the way. And are you correlating that in the right way?
It seems what you're prescribing is, oh, there's a way to document or communicate that at a station so that it's in a form that you could rely on and know that it's accurate and not just coming outta some tool. Who knows if that's really what occurred. Exactly.
And that's exactly what we're doing in the Intel community. It, it's a community of, uh, a bunch of security practitioners and companies, uh, really focused on, uh, this concept of observability and standardization of, of, uh, observation of supply chain metadata, and then how to enforce that as well. Um, so we're big members in that community, but we're only a part of it.
Um, uh, NYU Purdue, Google, Microsoft, uh, all attend the community meetings and, and make, uh, contributions, uh, uh, to that specification. Yeah, that's a very rich and active active group. Talk a little bit about, I'd love to hear, uh, more about testify sex, go to mar market plan and how you're kind of taking these ideas to market.
Yeah, Yeah. So we are building a platform judge, and this is built on our open core witness and archivist. Those are two CNCF projects, uh, that implement the in total specification witness is that pipeline observer.
Um, we're currently, uh, working on some integrations with GI GitLab. We'll have some announcements about that in, in the next couple months. And we have a GitHub action that allows you to create these attestations.
Um, and then IV Vista is the data store for all these attestations, right? And, um, it will store any attestation and total attestations that you create, whether that comes from the witness tool that, that we support, or another tool, uh, that generates, um, in total conformant attestations. Um, so what we've done is we've put this together in an AWS marketplace offering, along with some six components and a user interface that allows you to search these attestation.
So that's actually coming out in preview, um, uh, we're gonna releasing that in preview at CubeCon. Uh, so if you're interested in that, please, uh, reach out and we can set you up with a, with a trial of, uh, of that marketplace offering. Okay, very good.
And we'll with this at the end too, but if folks wanna reach out about that specifically, do they email you? com, what's the best way to raise your hand and say, I'd like to participate? Hey, Well, first of all, if you're at CubeCon, come out and, uh, say hi to us.
Um, we'll, I'll, we'll be walking around, uh, the show floor. We have a bunch of talks going on. Uh, but otherwise, if you're not, uh, visit our website, um, uh, and you can find a contact us, uh, or a, uh, uh, there's a button that says, uh, contact us for the preview and click that, fill out a form, and we'll get right back to you right away.
Excellent. Excellent. I, I'd love to kind of connect the dots to then, from what you've put together for this offering with, you have folks, the software developers, maybe DevOps engineers or folks that are managing the tools that are part of creating software.
You also have the what, where there's governance or whatever the name of the organization, part of the organization that's looking for this, uh, verification of, you know, software, supply chain security adaptations and things like that. Is your go-to market? Are you talking more to the developer folks, or are you think it's more the compliance teams that are saying, we have a way of helping you not make this such an onerous task, come look at these folks from Testify sec.
Well, we really provide value to both sides of that coin, right? I think our, our goal is to unite, uh, developers and, uh, cybersecurity teams. And, and we do that through this API, um, so for the developer, right?
We, we don't wanna create extra tasks for us. In fact, one of our customers, uh, they spend eight hours every single week moving the, uh, evidence from, uh, their, their supply chain platform into SharePoint. Um, so then it can be evaluated to see if they meet compliance or not, right?
We've eliminated that task from 'em now that developer is really focused on, on developing features, uh, rather than moving files around, right? So they're having a better experience. And then on the other side, right, that, uh, that, that ci IO that has to inspect this material, now they have it in a very organized fashion where can, they can generate some reports against it, and they have full visibility of that, that project that we're working on with them, right?
They don't have to go ask the developer, Hey, did you do your scans last week? Right? What are your vulnerabilities?
Right? Can, is this, is this artifact FedRAMP compliant? Like, these are things that we have that data for so that, that, um, that cis o or, uh, the security team can go look at it and really understand the state of that artifact.
Excellent. I mean, we always think about highly regulated industries, government, military as, as prime candidate for this kind of technology and, and needing these kind of solutions. Is that still primary target or do you, uh, audience or do you see now there's enough stuff going on, you know, the, the, the, uh, president's order on security and reporting, you know, breaks and compromises, and it seems like this is getting elevated for all of us, I guess, is what I'm trying to say.
It, It is, it is. But, but the problem is it's really expensive to comply with some of these regulations, right? So that's pushing a lot of the startups out of some of these markets.
And what we wanna do at here at Test fiac is over time really lower the cost of complying, uh, with things such as like EO 1 4 0 2 8, and the SSDF and d uh, NIST 800, uh, dash five three when it comes to software manufacturing, right? If we can lower that cost for these organizations, we can help them enter in that marketplace. Mm-Hmm.
Um, so that's really a core goal of, uh, what we wanna do here at Test Testify sec. Fantastic. You, you mentioned, uh, KubeCon and p doing some talks or things at Kub.
What kind of subjects are you talking about? I'm curious. Oh, wow.
We have so many talks. Um, let me, lemme look at my list here. Sure.
So one of 'em actually, uh, Cairo, um, he's a maintainer of RS Tough and he's doing a talk, um, on how you can use RS tough to, uh, secure any artifact repository. And I think he's using, uh, JFR Artifactory for that one. mm-Hmm.
Um, of Thomas Meadows. Um, he's our maintainer for witness and he's showing a integration between, um, a teston, which is a controller he built that takes, uh, Petron BPF traces for supply chain metadata, right? So that way now we can use the power of BPF to really inspect exactly, you know, what, um, uh, what is happening in our builds.
Um, this has the potential to possibly even mitigate things like, uh, solar winds or build system compromise. Mm-Hmm. So really interesting talk, take a look at that.
And then we have a panel discussion, uh, with our director of open source, uh, John Shell, uh, it's talking about, uh, SBOs and, uh, perspectives on cloud native, uh, security. So talking about, hey, what are the limitations of SBOs and what are the other tools that are out there to really do that full verification of the software supply chain, right? 'cause SBOs right, are just about that ingredients, but they, they don't tell us if those ingredients were assembled in in China, right?
So exactly. That Taco really be focused on, on how we fix some of those issues. It doesn't mean they were assembled, assembled in the right way either, right?
It's just No. Right. And there's a lot of issues with SBUs.
I think it's a really great tool, but it's got its limitations. I think there, there needs to be a little bit of additional education around that. So I'm really excited to hear that talk.
Yeah. I don't know if I'll be able to make it to all of them that the EI sounds one really in particular. If you, if you're dealing with things at the kernel level, obviously less chance something else is gonna get in the middle and, you know, compromise what you're seeing happening.
Yeah. That's the thing. If you can query the kernel, um, you know, you're, you're taking a lot of this stuff out of it, and you can, if you can, at least you have to have trust in something, right?
So if you can have trust in the kernel, that's great. I think there's some stuff coming out with confidential computing where we might not even have to do that in the future. But, uh, you know, there, there's a lot of really great work going on in supply chain security.
Um, Q Con should be pretty great. I know there's a lot of great talks. Well, fantastic.
Look forward to seeing you there and talking some more. Um, again, how can folks get ahold of you if they want to, you know, meet up at Kon or wanna find out more about how to join the, the early premier of your, of your product? Yeah, so, uh, LinkedIn is actually really great to get ahold of me.
Um, I'm pretty active on there. com, uh, hit contact us and we'll reach out right away. That goes right to our Slack, so we'll reach right out.
Otherwise, you know, you should find me at all these talks I just mentioned at CubeCon. And then, um, uh, like I said, we're releasing that AWS marketplace offering. So if you're, uh, looking to enhance your software, supply chain security, and you're looking at things like SCIO and SIG Store and at Access Station, uh, reach out.
I'm happy to talk just about what your problems are and, and some of the solutions we have to, to help accelerate some of those efforts. Fantastic. Well, good luck and, uh, congratulations on the progress so forward and look, look forward to seeing more great things from you and the testify SEC team.
Oh, yeah, yeah, it'll be great. Thanks for having me. You bet.
Cole, great to, uh, great to see you and we will, uh, see you again in a few weeks. Not too long from now. Thanks for joining us.