Closing Critical Blind Spots in Your SDLC; A Guide to Securing Development Pipelines with ASPM

Jimmy Xu:

Hi everyone. I’m excited to welcome you to the panel discussion from Cycode on Closing Critical Blind Spot in Your SDLC. I’m Jimmy Xu, Field CTO of Cycode. I’m excited to be a host for today’s panel discussion. As you can see my voice, I’m recovering from sickness, so this is not my normal voice, so hopefully you guys can still hear me. It’s a very exciting topic.

And first of all, for those of you in the audience who are new to Cycode and our webinar series, welcome. We have a monthly series where we tackle the big questions that are top of mind for the application security industry. For those who is joining us again, thank you, welcome again.

The goal for today’s discussion is to talk about the importance of securing your CIC pipelines, as they are the central mechanism to our software delivery process. To help me get started and to tackle this hard challenge, I’m delighted to welcome you to a seasoned cyber professional, a leader, a Cycode customer, Rory, Director of Product Security at Cribl.

So those of you who know me, I’m very passionate as a fellow practitioner of app security, and the role of product security is dear heart to me. I think that’s what we need as we envision as a role, combine that. So I’m just so excited, Rory, that have a fellow product security leader to talk about this, I think speak volume to credibility here.

So Rory, really, really excited. So let’s start with some introductions. Can you tell us a little bit about yourself?

Rory McEntee:

Sure, absolutely. So I’ve been in application product security for over a good decade now. Prior to that I was doing physical security in the military, so it was a fun transition. This role is a little easier on my knees. But it’s similar in that you have a mission that you need to accomplish and you have people and assets that you need to secure, and I’ve been in management most of my career. I had the opportunity to transition a couple times during COVID, but application security and cloud security are my bread and butter.

Jimmy Xu:

Thank you, Rory. [inaudible 00:02:35] military [inaudible 00:02:36], also a fellow veteran, so good to see you. Okay, before we get into it, just top of mind because I feel like software supply chain, pipeline security has been just a hot discussion in the form of app security. Rory, to you, just initially, why is the pipeline security top of mind for you?

Rory McEntee:

Well, Jimmy, you know and I both know that build pipelines are a very attractive target for bad actors. I mean, if I had a nickel for every pen test or incident report that said, “So then I popped the CI server and then I pivoted into production.”

I mean there are examples out there. One of the biggest ones is SolarWinds, was four or five years ago. Still feels pretty recent to me, probably because of how bad it was. I don’t recall if it was disclosed specifically how … There was a TeamCity CI server and really it sucked for JetBrains because they got negative press for this, but I mean it wasn’t a vulnerability in their CI server, TeamCity. It was just a misconfiguration, and misconfigurations are part of the OWASP top 10 now, but it can be overlooked. You’re securing your build pipeline as opposed to securing production. The build pipeline should always be considered a part of production, and I’m happy to say we’ve got a really positive story at Cribl that I’m happy to talk about too.

Jimmy Xu:

Okay yeah, I wanted to dive into that. But to your point, I mean, people like to talk about the SolarWinds, and then most recently this Verizon, talking about higher standards of software security. As far as I can remember, personally, as a fellow practitioner, if you compare it to the press, not just the press and the discussion in industry about app security, if you compare the amount of discussion around scanners securing the code for securing a pipeline, it’s almost unequal. Too much emphasize on let’s protect the artifact.

But to your point, the bad guys knows, the attackers knows that the weakness is the pipeline because it’s literally the single delivery mechanism to package and deploy all your current, any kind of artifacts when you deploy to cloud anywhere. Everything is delivered as code. So the mechanism is definitely has the weaker spots.

Rory McEntee:

Absolutely. And just because it’s not internet-facing, you always just have to do some compromise. You have to make your case to engineering teams, to leadership, to endorse and execute on a defense in depth strategy. I mean, it’s important to secure the doors and windows, sure, absolutely, 100%. But you have to monitor everything.

Jimmy Xu:

Yeah, and to your point, Rory, OWASP obviously did a good job, have top-10 in risk configuration. There’s also a couple of reference out there, we’ll talk about it later. But let’s start with this. Let’s get into some [inaudible 00:06:24]. In terms of securing the pipeline or the SDLC process, what are some of the common blind spots in SDLC, in reference to the pipeline, the build system, the deployment system itself. What are some of the blind spots that typically security team will struggle to address?

Rory McEntee:

Maybe I’ll answer that by maybe diving into why blind spots occur. I think blind spots often arise from a failure to scale a product security program. I mean, it’s vital to get software engineering teams or the teams that support engineering. So we have a productivity team at Cribl, they manage our CI/CD process, and we can’t just say, “Hey, our software is secure,” and hang up our hat at the end of the day.

They own services that either are production adjacent, and we treat them like production and we have to make sure that the assets in that environment are configured securely, patched, and monitored, and really scale an application security program or product security team program. The terms are used interchangeably. I usually refer to product security when we’re shipping a product on-prem, but also in the context of our job is also to secure the cloud environment.

So it’s done through establishing trust in meaningful relationships across engineering team. We’re advisors, we’re educators, sometimes motivational speakers, and also you have to build your program to make it developer-friendly. You have to select developer-friendly tools that can be tuned to minimize noise. No one likes noisy tools. I certainly don’t. You get your tools integrated on pull requests, you can use that to the drive ID, plug in adoption. You can teach teams to threat model when working on architecture design, and it’s not difficult, really, to teach the fundamentals of threat modeling. Someone coined the term evil brainstorming, so I like to use that. Secure coding education, running a security champions program.

I’m just really trying to work my way out of a job wherever I go. I say that in jest, but really it’s about creating a community of folks that are tuned into how security operates, where to report an incident, how to use the tools, what secure coding patterns do we have documented so that as the organization continues to grow, the senior engineers can mentor the junior engineers and we don’t drift from a state of good.

Jimmy Xu:

Yeah, I like the fact that you focus on the people, process, and the culture aspect of this. You can talk about tools all day, you can talk about blind spots in terms of capabilities, we can get to a little bit later. But yeah, I can tell you, obviously I’m taking that as the education, the enablement, empowerment, building the trust, extending that into educating them that it’s not just what you’re producing, what you’re getting from, where resources, it’s also the configuration of the pipeline that you might have access to, adding those curriculum into the whole process. But again, good point, if you’re not listening, if there’s tension, if there’s animosity, they’re not going to listen in. So thank you for highlighting that, and I can’t stress enough, I think that there’s so much discussion of tools, let’s not forget the people and process aspect of it. So if it’s receptive, then that’s one way to make sure that blind spots are addressed.

Now, I think you also answered the question of the common challenges. We know challenges is obviously when the culture is not there, but from a technical capability perspective, from a securing the pipeline, I think we talked about the misconfigurations. Are there any other areas you think commonly that things could go wrong in terms of a weakness, right, with top of threat modeling when you threat model a pipeline, what are some of the top two to three areas you think, other than the configuration of the pipeline system, you think we should pay attention to?

Rory McEntee:

I mean, you can’t go wrong with the basics. I mean, centralized authentication, we use an IDP, [inaudible 00:11:26], MFA. We don’t support SMS as a MFA factor. We really limit access to our build environment to lease privilege. It’s always going to be a winning strategy. And it’s not necessarily that you don’t trust your employees, but your employees can be compromised, and then they can do bad things with the stolen identity. And then number three is hardened through patch regularly. And I mean, we did those things early on at Cribl, and there was a conversation ahead, and we had to explain why we had to put in some hoops to jump through before you can access the build server.

But I mean, often it usually is a conversation. It’s like anything else. It’s like, “Oh, why do we need to fix this injection vulnerability?” Well, most developers are pretty savvy nowadays, but maybe you dive into a more obscure vulnerability, you have to explain why you have to do something. But I mean, it’s not just enough to one and done moment your assets. I’ll go ahead and plug Cycode here. We use Cycode to monitor our CI server for anomalous activity to make sure that our plugins are kept updated. Our productivity team does a great job, they update monthly. But also in a security role, we trust but we also have to verify. And maybe it turns out that a plugin will break something, or maybe there isn’t an update for a plugin, and there needs to be a conversation about getting a plugin replaced or figuring out how we can continue using it without breaking something else in the build.

And then when does that work need to be done by? What risk does it pose to use a plugin with a known vulnerability? Is it something that we have to fix within 30 days, or is it something that we can fix … Because if everything’s a high severity issue, then nothing is, right? And so it’s important that we pragmatically categorize the severity of issues based upon whether or not something could actually be exploited or not. And if you do that, you’ll always have a better chance of having the work prioritized on time. Because you’re being respectful to their workload, you’re being respectful to competing business interests, and where … Security is a type of quality, really, and there’s other things that the teams have to do.

And so I think it’s just very important to make sure that you have an honest conversation with the teams, secure the environment. But we’ve had a great success using Cycode, and integrating it with not only our CI/CD system, but our productivity tools as well to monitor for leak secrets. I’m probably preempting a lot of the questions here, but yeah, I’m happy to talk about how we monitor and respond to secrets that … Everyone does it. I’ve done it. He who is without sin, cast that first stone.

It is so easy, especially if you’re not in the practice of doing things securely, or maybe you’re brand new out of college and you’ve never used AWS Secrets Manager before, or HashiCorp Vault, and it’s not complicated systems to learn. And yes, is it slightly more work to follow good hygiene? Yes, but that is the cost of doing business.

And unfortunately we just treat it as an incident if something like serious gets late, it’s like, you got to revoke that immediately, and it’s not, “You’ll get to it within a week,” it’s, “Drop what you’re doing now and go revoke it, and then put the secret somewhere where it’s supposed to be stored.” And we’re really big on, all of Cribl uses an enterprise password manager. We’re always hammering the importance of using that and making sure that users are educated. It’s like half the battle. Half the battle, most of the battle.

Jimmy Xu:

Interesting. Obviously thank you for the lengthy response, obviously great discussion. I wonder what the audience is thinking, right? If they think what I’m thinking, I remember have a conversation, how do you secure the pipeline? It’s such a foreign concept, but if you listen to operationally how you guys do it, if you think about it, it’s no different than anything else. You just include that as part of that, right? You talked about treating it as another critical system that control the access, limiting access, right?

Operationally as far as patching, assessing what’s exposed, adding onto the threat model, continuous monitoring to detect a anomaly. Because if the attacker targeting the build system, the flow system, make some changes, you’re going to pick up if you monitor, right? Obviously very glad that you’re able to operationalize Cycode for that purpose. You also mentioned, I think it’s very important to highlight that the hygiene, it’s crazy.

You don’t just have to learn a program language. I remember when I was studying computer science in college, you got to understand how to deploy the cloud. You got to have access to all these cloud services as part of your full stack development. I mean, how do you expect a developer who is focused on innovating to remember how to do all these things? And you have access to it. It’s not only whatever that hopefully you’re using an existing encryption library, versus trying to write your own, God forbid, but access key to the cloud services, all that, you have access to that.

But obviously detecting secrets, hygiene in protecting secrets, certainly to me is one of those crown jewels that the attacker can use to compromise a pipeline, so thank you for saying that. So all that to say that it’s the same practice, you’re just extending that to the build systems, ensure that key management, secrets management is treated no different than anything else, but ensure that there’s coverage capability like a ASPM like Cycode that can cover that, right?

Rory McEntee:

That’s right. And I mean, we’ve built Cycode into, we’ve got a playbook in our [inaudible 00:19:08] program, so we monitor a set of tools for anomalous events and they’ll SLA on responding to that. We have the alerting to be very prominent and loud, and we always have someone on call to make sure that we’re monitoring for and responding to those alerts. Again, it’s the price of doing business. You don’t want to be late to the party when something bad is happening. You need to be [inaudible 00:19:42]-

Jimmy Xu:

I like when you say trust but verify monitoring, because if I … Anything, like nuggets for the audience, I always say it doesn’t matter your code artifacts, your cloud services, your pipeline, you cannot secure it by just scanning, scanning, scanning, remediation. You have to monitor, right?

Rory McEntee:

That’s right.

Jimmy Xu:

Ongoing detect, continuous monitoring, because things will change. So yeah, it’s just one nugget for the audience. You validate it, you have to make sure monitoring of your pipeline should be part of your securing the pipeline strategy.

Rory McEntee:

And maybe I should take the opportunity to plug Cribl too. So Cribl saves security and IT teams a silly amount of money. Really, when you consider the cost of ingest pricing for a lot of solutions out there, you can select the exact data elements you need, at whatever boundary you need to pull it from, you can encrypt and normalize the data on the fly. You can use Cribl Search, that’ll allow you to search and analyze your data wherever it resides, and you can figure out what data is actually relevant for you to pull into your SIM, for example, or a powerful tool. [inaudible 00:21:15]

Jimmy Xu:

Hey everyone looks like Rory is having connection issues, so let’s just give it a minute. So while we wait for Rory to dial back, just for audience, if you’re still listening, one of the things that we talked about, we heard what Cribl said about what they did in terms of practices and securing the pipeline. Obviously, great for them to see how they have operationalized ASPM tool like Cycode, but aside from the technology, another thing that, for audience, when you think about, “Hey, what reference, what industry best practices can I go look for as point of reference to see how am I going to secure the pipeline? What are some of the scripts?” Oh, there you are. Are you back? I think you’re on mute.

Rory McEntee:

There. Technical difficulties, not sure what happened.

Jimmy Xu:

Okay, no problem. So Rory, while you were reconnecting, I was telling the audience that we talked plenty about how Cribl did it. We talked about the ASPM tool. I was going to give audience little nuggets around what other industry best practice reference that they can look for in terms of a checklist, in terms of strategy, how to secure the pipeline. I was going to say that there’s two references I recommend, and feel free to add more.

The first one is, as we talked about, the OWASP. OWASP is definitely a great resource for anything. I mean, they even have lots of active contribution to AI stuff today. But as far as, in addition to the OWASP top 10, which you all know, there’s a OWASP CI/CD top 10, right? Specifically to CI/CD pipelines, thanks to the co-founders at a company, I’m not going to mention name here, acquired by Palo Alto, but it’s good reference.

Another thing I would recommend I, and Rory can use, I know that at Cycode we built a lot of our control checks based on a checklist, is CIS Benchmark. Many probably know CIS Benchmark, but how many do you know that there’s actually a CIS Benchmark on software supply chain security that has all the checks and balances, the configuration of the pipeline for all the STLC stages. Version 1.0 is out there. I know that at Cycode we are contributing version 2.0, but that’s a good reference, that’s vendor-agnostic, that can use as checklist. Rory, anything to add to use other than Cycode?

Rory McEntee:

Well, I really appreciate that Cycode has built-in support for helping you automate auditing of the SSDF. Some of our very early customers really required us to have a plan to implement SSDF. I mean, this was multiple years ago, and that was really when my team started being built. I was actually one of the later members of the team. Security is embedded, or product security, rather, is embedded within engineering in the organization. We have a CISO [inaudible 00:25:43] too, which we work with very closely. If you saw us working together, you wouldn’t know that we were not exactly joined at the hip org-wise, but our customers wanted to make sure that we had a plan in place to implement the processes outlined in the SSDF and we made that a priority as an organization, and we even had a third party come in and audit us and make sure that the processes were fully implemented.

And we have a very nice attestation that we have on our trust portal, and this is a two-year-old letter now, but it’s an attestation stating that, “Hey, this vendor, this security firm has looked through our documentation, they’ve gone through our process with us and they can confirm that we have implemented those processes.” But again, that’s a moment in time. It’s two years ago. You can use the Cycode platform to, one, automate some of those checks, but then also you can use it to put together a full, ongoing report that maybe you revisit quarterly or twice a year or something like that. And that’s more efficient than bringing in a third party every six or 12 months to do it, because I think it’s important that we did bring that third party in, but then we’re also self-auditing and making sure that we’re keeping all those best practices in place.

Jimmy Xu:

Thank you, SSDF is a good one, right? SSDF, obviously NIST came out, I have a couple versions already. It’s kind of like the gold standard with the executive order on the software security, all that. So great to hear that Cribl is already adopting that, and obviously combined with the self-attestation, and you’ve obviously got a good point. Don’t wait for external assessors. Yeah, you should always, maybe to a point, I remember as a consultant, I do a lot of these audits, right, in the past.

It’s great, but because things change so rapidly in our software world, so you want this to be continuous. Part of that is continuously attested monitor, self-attestation, right? Using a helper tool. So SSDF, to me it’s a good reference. It has a supply chain section as well as pipeline. Another thing, as you mentioned, I know that Cycode supports, is if you talking pipeline specific, it’s SLSA, right? Supply chain level for software artifacts, you have self-attestation you can use to [inaudible 00:28:43] your supply chain. So obviously something also Cycode supports, but you guys are using that as well?

Rory McEntee:

Oh, 100%. Oh, we have a supply chain specialist. His job is to make sure that those processes and controls are implemented. We’re a really big fan of SLSA, We just recently started using Walk, too. Cribl has been publishing software bills of material or SBOMs with every release for quite a while now. We’re very transparent with what goes into our software, and it’s the responsible thing to do. And I mean, obviously, yes, we have to keep our dependencies updated, and again, it’s the price of doing business.

Jimmy Xu:

I mean, I can help to promote Cribl here. Personally, we talk about SBOM, SBOM’s a buzzword. But for organizations, software companies that actually take the effort to actually generate SBOMs, to me, in my opinion as a practitioner, it shows commitment that you have to software security to your customers. So I think it’s really good and I think, hopefully, audience, you get take away not just trust Cribl, but also you see that, hey, there are companies that are not only talking about SBOM, they’re actually adopting SBOM. It’s really good that you guys have successful program. Any words of wisdom to share to the audience? How do you even do that with a SBOM program?

Rory McEntee:

I’m sorry, restate the question?

Jimmy Xu:

Any tips on how to even build a quick guide on building SBMO program. Because it’s very important for a software supply chain.

Rory McEntee:

Well, right. I mean, if you have a bunch of vulnerable stuff in your code base, you’re going to want to fix that before you start advertising, especially if there’s anything exploitable. So I mean, the easiest way is just to make sure that everything’s updated to the latest, have to account for operational risk. Some dependencies get abandoned, and you’re going to have to have to rip it out and swap it out with something else, and that sucks. But I mean, that’s what our customers expected, was we sell to security teams, security and IT teams, but they demand that we … It is their expectation and demand, their requirement that we are building secure software, and we’re being transparent about our program. And it’s not a matter of if, it’s when is that dependency going to be updated? Even, there’s a lot of talk about assessing whether or not something is actually vulnerable based upon a dependency, depending on how you use [inaudible 00:31:31].

I think that’s a very important factor in determining what the actual severity of the issue is in the context of your own application. But you’re still going to have to update it. Because the tester is like, “That’s cool, I believe that. But our policy is we’re not allowed to use software that use components with known vulnerabilities.” So you still have to update it. It might be, maybe not this release, but maybe next release. And we’re always really transparent with customers on when we’re going to fix things, or at least, I can’t make promises on behalf of the business, but we have a really good track record of fixing issues according to our SLI.

Jimmy Xu:

Yeah, thank you. I’m glad to really hearing in real practice, the takeaway is being transparent. You know, to your point, to do everything you can, which is going to get into prioritization, but you know you can fix everything that you can own. It’s more around showing track records, disclosing what you can do and being transparent about it. I think that’s really, really important for folks. Not idealizing the impossible, but also understand, hey, what works. That’s like the middle ground.

Now speaking of prioritization, we got to talk about prioritization. Because you talked about what’s actually being used or exportable or all that, right? I mean, as a fellow practitioner, it’s one thing you can talk all day about, “Hey, let’s build some trust with developers. Let’s educate them, let’s bring them in, let’s enable them.” But nothing annoys the developer more when you dump tens and thousands of vulnerabilities from your pipeline, your SaaS scanning, your cloud configuration, your IAC, your container, “Here you go, here’s 10,000 vulnerabilities. Knock yourself out.” That’s not a good way to build trust.

So that’s why, obviously, the way you mentioned already earlier, and using ASPM, obviously it’s about prioritization. So curious from a Cribl perspective, I mean, you can always use a tool, but what factors do you guys use in general speaking, any kind of risk scoring? How do you basically, essentially, prioritization will be based on risk? What factor does Cribl used to prioritize your vulnerability and risks and threats in terms of risk?

Rory McEntee:

Right, so I mean, there’s always the CVSS and to be honest, I haven’t really reviewed v4 yet, but I think it’s out now. But I’m not a huge fan of v3, because it just seemed like no matter how we plug things into the calculator, even with temporal scoring, it just seemed like everything’s kind of a high. I’m really excited to see a more adoption of the exploit prediction scoring system or the EPSS. It is a framework that a company … It’s another data point. It’s used to predict the likelihood that a vulnerability will actually be exploited in the wild, allowing organizations to actually prioritize a vulnerability management in a chromatic way that really enables the business. If you’re fussing over every low every month, man, your vulnerabilities management program’s really going to drag. Fortunately for us in Cribl.Cloud, we’ve got patching down once a week, so it’s never really a problem for us.

It’s almost on easy mode in a sense, but it allows us to work on other things, so I don’t take it for granted at all. For application security specifically, give Bugcrowd a shout-out, just because I really like their vulnerability rating taxonomy or VRT. They’ve iterated on that like over a dozen times now and it’s a really good quick reference for mapping what does the industry considered this type of vulnerability? And then of course it’s like, take into the context. Is it internet-facing? If it’s not interfacing, it’s definitely, the priority is a little lower, right? Do you have to be authenticated? Do you have to be an admin? How complicated is the exploit? Or is there a public exploit available? Is the exploit reliable? Well, does it cause system instability? There’s a lot of factors that go into place.

I mean obviously the answer is just fix it, but is it, do we need to drop what we’re doing now and disrupt the sprint cycle, or can it wait for the next release? Is always a question that we should be asking ourselves. Because you hit that red button too many times for the wrong reasons, you’re going to lose traction. And that hurts the program, that hurts the mission, and so it’s important to be pragmatic about vulnerability management.

Jimmy Xu:

I just love the discussion. I think literally I can talk all day with you here just about that vulnerability management topic. I suggest, audience, if you got bored earlier, this part from Rory, you might need to replay it back. Because everything you said I’ve done as well on the other side, being a practitioner, being consultant. Because to your point, I’ll summarize for you, see if you agree, right?

I mean the obvious insufficient thing to do is just based on CVSS. I think with crap out of CVSS even version 4.0 got gaps too. There’s plenty discussions. The easy button of just in focus on CVSS is critical, the highest of 7.0 is not sufficient. Everything Rory talked about, the EPSS, there’s also CSEC, [inaudible 00:37:55] known exploitable vulnerabilities, the exploitability of something factor in the sprint cycle, all that.

So I remember building flow charts, and sounds like Cribl has a very mature and complicated, which is not a bad thing at all, with assessing, prioritizing risk. So it’s good to hear, right? The takeaway is that you have to, for an audience, apply all these tools and factors and really be deliberate around the process. It is a complete process. It’s not just using the critical high and thorough defense. Go through that and then be realistic about remediation.

Rory McEntee:

I’ll give you a good example of why you have to be pragmatic around vulnerability management, and then also advertise another win that my team delivered this year. So we ship Cribl on two Docker images. One is Ubuntu, and if you run Ubuntu through a Trivy scanner or a container scanner, you’re going to get CDs. Now the CDs are not exploitable usually, but they’re constantly patching CDs. But there is a dozen or so CDs that either they’re still, there’s not enough information, or they’re not exploitable or for whatever reason, the CD is just going to persist in the image month after month.

And so I personally don’t like having to ask security teams to get exceptions to run our software when our core demographic customers are security teams. It’s a bad look. So we started shipping Cribl also on Chainguard Wolfi Linux, which, very cool. If you run it through a scanner, it’s consistently zero CDs and no more exceptions are needed. And we release on Chainguard Wolfi, and it’s also half the size too. So it’s a really slimmed down version of Linux. Chainguard’s a really cool company. I recommend if folks are running into a similar issue. Very, very, very cool stuff they’re doing over there.

Jimmy Xu:

Absolutely, yeah. I know Chainguard really well. I know folks over there. I think the key takeaway for that is going back to the topic of vul management. You cannot scan to secure, especially when you have known vulnerabilities in the … Like people talk about, “Let’s secure base image.” You know how difficult that is to make it functional? And to your point, some CD does not go away. So this goes secure by design, secure by default, having a pre-hardened image as a service by using a third party like that, you save a lot of the time. So it will naturally become clean when you’re going through your ASPN, running through your CNAP, it’s way easier, because the [inaudible 00:41:09] is way smaller, a lot less. Over time, it reduce. So that’s a takeaway, right?

Rory McEntee:

And it’s not just, “Okay, we’re passing these container vulnerability scans, we’re reducing the sales cycle too. Because I’ve seen POVs get delayed because of our containers getting flagged by vulnerability scans. That needs to go away. Let’s remove that from the conversation. Security can’t be a reason why people don’t adopt Cribl. That’s flat out, I am so passionate about that. And so that was just one less thing that we have to worry about now, because it was always something that was coming up with customers with high security requirements. And fortunately the market has a solution now. So we’re very happy about that.

Jimmy Xu:

So I was going to close on that, because again, I feel like we could talk all day. Because sometime when we preach, I remember being in your shoes preaching, you had to apply innovation, because what you mentioned is more of an innovative way, versus a legacy process of having security. You remember those questionnaires, manual questionnaires got to go through every time?

Rory McEntee:

Yeah.

Jimmy Xu:

I like the fact that you talked about, like I was going to ask, “Hey, how do you incentivize developers?” In this case, the Cribl customers. But the thing is, create the roadblocks. You mentioned, just put the foot down, security cannot be the reason, right? So that’s very powerful. I think that’s a very good takeaway for the audience, is you have to be willing to clear the roadblocks. Don’t just say, “Okay, I’m going to train you, I’m educate you, but yeah, sorry, you still got to go through all the legacy processes. Can’t really help you make faster. You got to go through all these 10,000 steps.” No, actually we’re going to actually make it easy for you.

Rory McEntee:

It’s really important. I mean if you want your processes to be adopted by engineering teams, they got to be easy to adopt. One of the things we do with our static analysis solution is we write custom rules. and we can also attach confidence levels to rules, too, and so we can set the threshold based off of something that is a high priority, high confidence rule. But then if something is a low severity and also low confidence, maybe it’s not something that needs to be blocking on a PR, but we can still provide that feedback. You can continuously improve your tools and your program, and I think you’re never really done. You’re always building something new, and it’s important that you’re better than you were yesterday.

Jimmy Xu:

Yeah, thank you. To summarize this, yeah, make the easy way the right way. I remember running [inaudible 00:44:13] team. It could be people dedicated writing SaaS rules, because those things help. Otherwise it’d be very noisy. So if you feel like you have nothing to do with it, you’re not doing anything right. So thank you for closing on that. Key takeaway, always room for improvement, take action, and hopefully that’s what you’ll take away today. Rory, really appreciate it.

We’ll wrap it up, session here. Special thanks to you for diving into this topic. I think really a lot of nuggets for … And thank you for sharing the nuggets of how you run it at Cribl, and hopefully audience takeaway of not just the concept, but in practice what worked in a very important organization? So again, thank you for your time, Rory, and for information for the audience. Anything else, additional resources, you can go to our website. If you want to connect with me or Rory directly, feel free to reach out via LinkedIn. And thank you for joining us and have a great day. And Rory, thank you.

Rory McEntee:

Thank you for having me. Take care.

Jimmy Xu:

Bye.