Press Release
The “buzz” in building more secure applications is “shift security left,” which means integrating security into and throughout the Software Development Lifecycle (SDLC).
The Software Assurance Maturity Model (SAMM) is an excellent tool from OWASP that provides a framework for assessing and improving your development processes, resulting in more secure applications. In this episode, your host, John Verry, CISO and Managing Partner at Pivot Point Security, sits down with Sebastien Deleersnyder, co-lead of the OWASP SAMM project, to discuss in depth how you can use SAMM to improve your application security program.
Join us as we discuss the following:
- The biggest challenge teams face in developing secure applications
- Using OWASP SAMM to assess your current security process
- Where most orgs really are today in terms of AppSec
- Identifying quick wins to improve web app security
- Leveraging SAMM alongside other security frameworks like NIST 800-218 and ISO 27001
To hear this episode and many more like it, we encourage you to subscribe to the Virtual CISO Podcast on our YouTube here.
To Stay up to date with the newest podcast releases, follow us on LinkedIn here.
Listening on a desktop & can’t see the links? Just search for The Virtual CISO Podcast in your favorite podcast player.
See Below for the full transcription of this episode!
John Verry (00:00):
Uh, hey there, and welcome to yet another episode of the Virtual CISO podcast with you as always your host, John Very, and with me today, Sebastian Deli Snyder. And I hope I got that right,
Sebastien Deleersnyder (00:12):
Sort of, but it’s, it’s a hard name for, for English speaking people, uh, to pronounce it. So I’m, I’m not a native e English speaking person. I’m, I’m from Belgium. So, uh, thanks, thanks for having me, uh, John on this, uh, podcast.
John Verry (00:24):
All right. So now, now, now I have to ask, what is the proper pronunciation of your last name?
Sebastien Deleersnyder (00:29):
So it’s, uh, it’s, if, if it’s done in, in Dutch, it’s Sebastian. Uh, but in in English, it’s Sebastian del Schneider.
John Verry (00:38):
Okay. I wasn’t that bad off Right. <laugh> for an English speaking person, that wasn’t too bad.
Sebastien Deleersnyder (00:45):
But, uh, I, when I, when I reserve something like a hotel or, or a restaurant, I always give my first name because if, if I need to spell my second name, it
John Verry (00:54):
Takes, it takes a little bit of time. Yeah, it took me a little bit of time when I was, when I was typing up the, uh, the intro, it took me twice to go back and make sure that I got your name spelled right. So, uh, again, thank you for jumping on and especially thank you for jumping on. I know that you’re in Belgium right now, so you’re recording this in your evening. So, uh, my appreciation for that. Um, always like to start simple. Tell us a little bit about who you are and what is it that you do every day.
Sebastien Deleersnyder (01:19):
So, um, I’m, I’m one of the co-founders for a company here in Belgium called, uh, tok, uh, where, uh, we do the mainly cybersecurity consulting. That’s our core business. Uh, that’s also, uh, what I’ve been doing personally for the last 20, 20 plus years. Uh, graduate, graduated as a, as a master in software engineering around 95. So in the previous century. Um, did some development a couple of years and then, uh, but switched over to the quote unquote dark side, uh, to security around 2000. And, um, and have been doing that ever since. And with my background in, uh, in development, really got interested really quickly in, in software security, application security, uh, both professionally, but also, um, as a volunteer, discovered an organization called O osp, uh, around 2004. Uh, it, it’s, uh, uh, nearly 20, well, it’s over 20 years now, um, that, uh, the WASP already exists.
(02:19):
Uh, but I discovered in 2004, joined the first conference, uh, of OWA in, uh, in the, in the uk actually in Royal Hallway in 2005. They asked for volunteers to start up local chapters, which I did in 2005 in Belgium. And from there on, uh, what started really as a, as a hobby, uh, uh, grew out to be a, a major significant part of my professional life as well. I’ve been quite involved in o OSP as an organization. Um, and so both professionally, I’m, I’m involved in, in application security, but I’ve been doing quite some projects, um, and organizing quite some events also, uh, with, uh, with O osp.
John Verry (02:57):
Gotcha. Uh, always ask, what’s your drink of choice?
Sebastien Deleersnyder (03:01):
Well, being from Belgium,
John Verry (03:04):
Okay, it’s gotta be Atlantic,
Sebastien Deleersnyder (03:05):
Right? <laugh>, <laugh>, uh, we, we, well, we had, we have really, really good beers in Belgium,
John Verry (03:11):
The world’s best, arguably the world’s
Sebastien Deleersnyder (03:13):
Best. Oh, I actually, there’s, there’s quite some,
John Verry (03:16):
Oh, there, so there’s a lot of great beers now, but I mean, the classic Belgian beers
Sebastien Deleersnyder (03:20):
Are the, but, but one of the, one of the, the, the best beers in Belgium is called West Platon. I’m, I don’t know if you’re familiar with it mm-hmm. <affirmative>, but it’s a Trappist beer that’s really, really good, but, but hard to get by.
John Verry (03:30):
Yeah. I’m a, I, I, I, I tend to like trappist style beers. Uh, there’s a, there’s a, a, a, a distill, not a distillery, a brewery here in the US called Umang mm-hmm. <affirmative>, uh, that actually, uh, does something called three philosophers. And it’s, they, they, they licensed it from one of the Belgian breweries over that way. So, yeah, I, yeah, I think your beers are absolutely wonderful. Uh, so I was figuring you were gonna say that, at least I was hoping you were gonna say that. Yes. Because Belgian Belgians bring a smile to my face. Um, you know, I, I really enjoy them. Um, okay, cool. So, uh, it’s awesome to have you on. Um, it, you know, I’ve been doing this a little bit as you have been, you know, so somewhere after y2k, uh, if we all remember that, you know, I think the world got a little bit more serious about security, right?
(04:18):
Microsoft started building secure by default from a Windows perspective mm-hmm. As opposed to, you know, wide open by default. Um, you know, you mentioned Owas, but they’ve been around a while, around 2003, I believe was the first iteration of the Owas top 10, you know, which is one of the hallmark, uh, standards of, of any information security, uh, entity. And, um, you know, we’re now 19 years later, but still <laugh>, the injection attacks still sits a top the O os top 10. Uh, so you know, what we’ve done, which I think has been largely, you know, substative style testing, you know, at the Applic, you know, from an application security perspective, dynamic application security testing, a little bit of static, um, hasn’t been as successful as we’d like, which is, I think why we’re seeing, um, somewhat driven by the government, somewhat driven by our own risk, uh, tolerance, uh, this movement towards what we call shift left.
(05:18):
Uh, and I think that’s gotta make you happy as somebody who’s actively involved in sam, um, because, you know, that’s, that’s this idea of secure by design. So that’s, that’s the prop topic of today, which is awesome. Um, so just to kinda make sure we’re on the same page, can you define what an SDLC is as the SAM is around that? And, and I’d be professionally curious. Increasingly, you’re hearing SDLC s sdlc, and now the new one I hear a lot of is sdl. Uh, and if you have a, a, a favorite for, for which acronym you’d like to use, let me know about that as well.
Sebastien Deleersnyder (05:53):
Well, yeah, SDL is the shorter, the shortest version. Um, but it’s, it’s actually also the, the one that Microsoft started with a secure development life cycle. I’m, I don’t have a, like a preference for one or the other. The, uh, I think the, the philosophy behind a secure development life cycle is that, um, you have to build in security as part of the development process. And so you have to integrate that as part of the, uh, development, uh, life cycle, uh, because software process has, uh, has grown enormously, uh, in terms of complexity and in terms of, um, what you can do with it, uh, over the last 20 years. And also, I think we have been doing quite a lot of things, uh, in, I would say in the security industry. But if you look at how the software industry as a whole has grown, um, uh, and achieved a lot of really interesting, uh, I would say, um, uh, products that are out there, um, then that’s, that’s really our biggest challenge.
(07:01):
Uh, how can we keep up with the speed of software development? And the only way, in my opinion, and also I think in the opinion of lots of people that are involved, is to be able to secure or help secure software, um, aligned with, with the people who do it. So to align your activities with the development activities themselves. Um, so that’s, that’s in, in essence what secure development life cyclists. There is no magical dusts that we can sprinkle over the software or on off button at the end to say, let’s switch on the security aspect. That’s not, that’s not there, there is no silver bullet for that. So the, um, so we have to think about how is software being created, what are the phases that we can, uh, in work together? I would say with the people involved and how we can be, make sure that, uh, security is an integral part of that.
John Verry (07:53):
Um, I, I think you might agree that it would be fair to say that, um, one of the great things about, probably for most organizations, the first thing that you would do with the SAM is to assess where you are. Um, yeah. A do you agree? And B, can you talk through how you would use SAM from an assessment perspective?
Sebastien Deleersnyder (08:12):
Mm-hmm. <affirmative>. So, so let, let’s, let’s maybe take a small step back and, and explain what, what SAM is really about. And so some is the software assurance maturity model. And, um, and what sets some, aside from a couple of other models is that it’s the maturity part. So it’s the maturity model in a way that, um, it allows for organizations to understand where they are and how they can improve themselves in terms of maturity. Uh, and for that, the, the model itself has a couple of aspects or characteristics that are really, um, interesting. So, and there’s a, there’s a couple of reasons for that. So if you are going to start or improve, uh, your, your own sdl, um, you’ll need to realize that this is something that’s going to take some time and some iterations to do so. So you have to do this in a, in an iterative way.
(09:07):
You also have to align this on the risk profile and, and, uh, and risk level of your, of your software within your, I would say, portfolio of applications. So you have to take that into account as well. And it has to be something that helps you to understand what you can do in terms of activities. Um, and, and that’s where some comes into play. It covers for those, but most importantly, some helps you to measure those security activities that are part of your sdl. And once you can measure them, you can manage them. And so that’s, that’s the whole philosophy, uh, of, uh, of the model. And within that model, some, it’s built out of like a couple of like five business functions with each three security practices. So in, in total 15 security practices from, from strategy and metrics over design, implementation, verification, operations of software where each of these practices have a certain level being from zero, or you’re not doing, or you’re not measuring your security practice up until one, you’re doing that, um, on an ad basis just as, as needed towards a level two, which is more efficiently.
(10:22):
Uh, and you are, you are aligning really your, your practice towards your software. Uh, maybe for instance, you are aligning your testing policy of your tooling towards application and scope up until a level three where you’re fully mastering that, that that practice, um, you’re becoming better at it, but you’re also putting feedback loops into your own sdl. So you’re learning from your, for instance, your security test to fix hopefully your software, but you also three them as symptoms of like, what went wrong, where in, uh, in our software life cycle did, did this, uh, book, or was this book introduced, and how can we get to the root cause of that? And that’s a level three act, I would say, uh, type of activity. And so those are the, the maturity levels we have in some, over each of these 15 security practices. And, uh, the ID there is that you don’t necessarily need to aim for the highest level for each of these security practices. Um, but obviously you first need to understand where you are and where you want to go with this and that, that’s the, this first step, like assessing where you are currently in your, in your current, I would say SDL journey.
John Verry (11:37):
In terms of, um, you know, I’m assuming you, you do security consulting, I’m assuming it’s focused on a, a application security, and I’m assuming, uh, that you leveraged the SAM in your consulting. Um, where would you say that a typical organization’s maturity level ends up sitting? I mean, can you generalize or, or not, you know, what, what, what, what are you seeing these days?
Sebastien Deleersnyder (12:00):
Yeah. Um, there’s a couple of, well, obviously VI Victorian, we do, we do quite some <inaudible> consulting. Uh, we have the, uh, we don’t only do Abse consulting, which is interesting because we can align and, and link, uh, in terms of what we do around <inaudible> consulting also to governance risk compliance, which we do architecture, which we do ethical hacking and so on. So it’s, it’s, it’s, I would say the full picture of services that we, that we typically do, um, from our own experience, we, we obviously help help a lot of customers with, uh, with some assessments and some roadmaps. I would say it’s everywhere, probably between one and two on average, uh, for, for most organizations. Um, but another interesting data point is that with, uh, with o some, we did a survey, uh, last, uh, last November last month, where we asked, um, what the average, uh, sum level is that, uh, most organizations have. And, uh, so, and I would say the average, uh, of overall some level is at this stage, yeah, from the, the people who responded, we had quite some, uh, we had more than 160 organizations responding to that on an average of bundle to two. Uh, in, on the level between zero and four, uh, sorry, zero and three, yes. Right
John Verry (13:21):
Now, I would think that the people that would a, know about owa, Sam and B, would respond to a questionnaire of that nature. They’re not your average, average organization. They’re actually gonna be ahead of the curve, right? So if you’re talking about there, let’s say at a one and a half, you know, I, I, I think that in the better orgs that we see that one and a half two makes some sense, uh, and we see, we go into some other organizations and, you know, sub-zero, excuse me, sub one is not an unusual no circumstance. Okay. Yeah. Yeah. And agree with that. And then question for you, do you see, I’d be curious as to, you know, so there are five core domains, right? We’ve got governance, design, implementation, verification, and operations. Do you see different differing maturity levels across each of those different domains? You know, I would think that, you know, more, the implementation verification is more the sweet spot for most people. Maybe that’s a little bit higher, where I think, you know, operational, the, you know, threat modeling and some of the governance stuff seems to escape. Some people,
Sebastien Deleersnyder (14:26):
It, it, it really depends on the kind of organization. Um, it, it’s based on the on, on the size and the scope of some implementation. Uh, you, you come across different kinds of numbers. Um, also out, out of the survey, we’ve learned that it’s being used a lot in smaller organizations, but also like there were bigger organizations like 100,000 plus, uh, employees, um, that, that actually use some. Now what we see, especially with, I would say the somewhat smaller scale up, like organizations where it’s more like a between brackets, bottom up approach from like doing testing, uh, having secure build security implementation, um, or really the build deploy parts, really, they have that under control. They know how to do that. They have quite high scores there, but they’re lacking behind on the governance part, uh, just simply because the governance part of some is much more focused on little bit of formalization, like aligning, uh, your activities with, with stakeholder risk, appetite and so on.
(15:31):
And having like some kind of KPIs around the, the apsec, uh, uh, activities, which makes sense. Um, but from, uh, if it’s driven by development teams themselves, you see that less, uh, they, they do this out of, I would say, um, with the technical approach, but less with the governance approach. Whereas if you flip it around and see it for, uh, bigger organizations that, uh, are really pu pushing this true more like from a top down approach where governance is leading, uh, you see higher scores in the governance part is also in the operations part where incident response is really under control, uh, and lower scores on the, on the architecture, um, implementation and verification.
John Verry (16:17):
Gotcha. So we go through the assessment process, right? And we get a score for each of the 15, uh, areas. Mm-hmm. <affirmative>, you know, the three areas under each of the domains that we discussed. Um, how do you recommend to somebody that they set their targets after they look at those scores? Is that, is that risk-based? Um, do you believe that there’s a order of precedence that makes more sense, you know, in terms of the, which domains should, should proceed, other domains? What, what are your thoughts there?
Sebastien Deleersnyder (16:48):
Uh, I’ll actually first go to the assessment part, um, mm-hmm. <affirmative>, because there is one thing which is important to understand with some that is the target audience for some is specifically not the developers. It’s more like whomever’s going to be in charge for setting up an APSEC program mm-hmm. <affirmative>. Um, and the worst way that you would do some assessment is sent the spreadsheets, which we use a lot for, for assessments, uh, towards your development teams and say, Hey, can you do this, uh, self-assessment? Um, that’s, that’s not really going to work. Uh, the, the best way to do the assessment is true workshop style, interview style, have a, have a really good understanding of what, uh, what teams are actually doing. Um, and out of that, you’ll already identify quite some quick wins and improvements, uh, of what they’re already doing to make, I would say, quick progress based on, on their current, uh, current practice.
(17:47):
So that’s, that’s one thing as an input. Mm-hmm. <affirmative>. The second aspect is in terms of setting target, that’s, it’s actually the hardest part of a, of a sub implementation project because you need to align both, uh, what’s what’s really necessary for the applications, the software in scope, the risk profile, but you need to align it with, with risk appetite from the business owners, uh, risk appetite also from, from the stakeholders, uh, but also speed of development, like, how fast can we do this? Is there, is there an understanding for need to, uh, to do this? Um, and what are the resources that that organizations are actually having? And you can’t, I would say you can’t speed it up really fast. You, you need to also align with the, with the next release of an important piece of software, which you could take as a pilot project. So there’s a couple of things there that you, that you need to align. So it’s going to be based a little bit on, on those aspects. So like, what’s, what’s a good pilot team to start it off with? What can you learn from that? How can you then, uh, take that and, and take that as a lessons learned for pushing this through in the, in the rest of the organization.
John Verry (19:01):
Gotcha. And then going back to that idea of prioritizing, um, you know, so it, it’s gonna be based on a number of those things, right? You know, the, the risks associated with a particular gap that we’re seeing an organization’s ability to close that gap in a per, in a particular unit of time. Um, do you find that there are, is any of the domains which are, uh, you tend to prioritize over others?
Sebastien Deleersnyder (19:24):
Yes. So there’s, there’s a couple of aspects that are really crucial. Uh, I think certainly in, uh, I would say at the, for organizations that are still quite new to this or where there’s, I would say the buy-in is not that high yet, education and guidance is really key. So you really need to make sure that whomever is involved in, in your coding processes, understands the, understand the risk of, uh, uh, aspects and need to get some proper training. That’s, that’s a very foundational part of every, uh, implementation. Uh, and the second part is that to make this scalable is to introduce the security champions in the whole, in the whole setup where you, you want to embed security as part of the team, uh, not only by one person, but also making sure that the team is set accountable for security as part of their job to be done.
(20:18):
Um, so those, that education and guidance is a really important one. Obviously, the testing part needs to be more based on the requirements. So if you have requirements under control, testing will go better as well. And then, um, the threat assessment, so having application risk profiles and threat modeling, I really see as a flipping point between organizations that are lower immaturity and organizations that are higher immaturity, because as tre molding might seem a, an activity that takes some time and might slow down, it actually helps a lot of organizations to speed up their, uh, their secure development processes because you are ingraining security as part of a decision process of what to do or what not to do in terms of security and aligning a team on that. Um, and it’ll allow for a faster deployment, uh, later on.
John Verry (21:12):
So I like your idea of making sure that there’s accountability for security, right? A, a any security program needs tone at the top, right? Say if some somebody doesn’t own the program, if somebody’s not enforcing that this is important, and making sure that people have the understanding of that and the resourcing that’s necessary to accomplish it, right? It’s not gonna be successful in terms of that education. Um, I’m assuming that that education would be across the entire, uh, development team, right? There’s, there’s the coders themselves, right? Um, but also making sure that whoever is responsible for that understands, you know, good application security practices, especially the people that are, that are governing the program. Um, do you find that, and, and you mentioned specifically threat modeling. Do you find that that is, that seems to me to be an area that I’m always surprised how little knowledge that we find many organizations. Um, do you have a preferable, you know, are you, uh, hey, a, a stride or dread kind of guy? Or are you just like, look, guys, at the end of the day, threat modeling’s about understanding the risks to the information and the application, you can do any approach that you want as long as you’re doing a good job of thinking through risk and making sure that we know what risks we’re managing with the controls that we’re putting in place. Mm-hmm. <affirmative>.
Sebastien Deleersnyder (22:28):
So I’m, uh, I do teach threat modeling a lot, uh, to, uh, to, to teams. Um, and while we use Stride, uh, to, to teach people on how to do tr modeling to cover like the four question framework, whether you’re building, what are you threats, what technical countermeasures are you going to look at? But the most importantly, what have you learned from this? Mm-hmm. <affirmative> Stride is a, is a, is a good, um, way to introduce a developer to potential threats. Like, it’s, it’s, it’s has been around there for years, actually was invented by a couple of smart guys at Microsoft, uh, and in, in 98 already. So it’s, it’s even older than osp. Uh, but it’s only one example of a potential list of threats. Uh, you can also go as far as looking at attack framework or other, uh, other, other frameworks looking what potentially can go wrong in your software. The most important thing is the process itself and get, and, and learning from that process as a team and aligning it with, uh, what the team can do. And at a certain point in time, you will need to have, or to introduce somebody with some security knowledge in that loop. It’s inevitable, but making sure that you identify those moments in time to call in somebody or to have somebody on the team who can have a look at it, uh, and together with the team decide on the best way for it.
John Verry (23:51):
Gotcha. So to me, oasp is the, the leading software organization in the world. I’m a massive fan of all of their content. Uh, I would assume that from an education perspective, uh, some of the other great guidance, you know, most notably probably application security verification standard, uh, perhaps even the owas top 10, at least as an informational and awareness, uh, document. Um, what, what else are you using? You know, are, are you using those as part of that education program? Uh, and are there other things that you would recommend from an education program for the team? Mm-hmm.
Sebastien Deleersnyder (24:23):
<affirmative>. Yeah. So, but indeed, uh, so some and a svs go, go really well together where some provides the umbrella, yes. And, and a SVS is, okay, what are your requirements? How are you going to test this? Uh, also there’s a really good version for mobile as well, the mobile a svs. Yes. And the testing guide there, um, where other projects that are really, really good, uh, is, are the cheat sheet series mm-hmm. <affirmative>. And so there’s, there’s really good cheat sheets out there on every topic imaginable. Um, and one of the, the tools obviously is OWA zap. So to do dynamic testing, uh, ZAP has evolved enormously is I think by far one of the better dynamic security testing tools. Um, certainly, and I would say if you would compare to paid four tools, uh, which you can also, I would say deploy in headless mode as part of your C I C D pipeline. So that is definitely, uh, one of the, the go-to projects. Um, knowledge security framework is a good one to train, uh, to train people. So there’s, there’s lots of them. Uh, but those are the ones that come to mind and are, have, I have seen, uh, I would say in practice a lot.
John Verry (25:34):
Gotcha. All right. So we go through this assessment, Mary, we begin to prioritize, um, what areas we should be focused on. We make sure that we’ve got the right educational component, you know, for, for these individuals. Um, what next is it, uh, do you, do you see it as, I would imagine that you probably take a go slow and iterate approach, right? So if somebody says, Hey, we’re sitting at a 0.5 and they say, Sebastian, we’d love to jump to like a, a 2.5, you’re probably gonna look at them and go, yeah, let’s not, let’s not try to do that. Right? So what do you look at as being a manageable change? And, and then I’m assuming that what you’d recommend to folks is that once we’ve gone through, let’s iterate, let’s make sure that we’re where we are, and then let’s set the next, you know, so it’s almost like sprints in the way that you would do software development.
Sebastien Deleersnyder (26:26):
Yeah. And, and that’s, that’s exactly what it is. Uh, it’s, it’s setting your own sum sprints, uh, but you don’t align them on, on actual sprints in the, in, in the teams because they’re, they’re going at sprints for like, like between two and, and four weeks. Mm-hmm. <affirmative>, uh, I would align and I I, with most organizations that we align with, we align sprint more on the, on the major releases or on like water or even like six months, six months iterations, depending on, on the, on the type of organization and their appetites, uh, I would say for change. And also the way that they can start doing this, uh, because you really want for the, the changes to take effect, to measure those effects, to see what, when, once you’ve done training, once you’ve started doing some of the activities, you want to have period where you measure the outcome of that.
(27:22):
Are, is the software getting better? Are we seeing the numbers of design, of, of vulnerabilities? Are they going down, uh, at a certain point, uh, point in time? So six months, uh, of iterations typically are, is what we see in over horizon of, of over two or sometimes even three years, uh, where organizations grow up until a level that is good enough for them. Uh, and it, I always say it’s not the, the target maturity level, it’s what kind of target activities do you really want to integrate in your organization or in the way that you’re working, aligned obviously on, on the applications that are important for you.
John Verry (28:01):
Gotcha. And let’s say that we do get hit your, so you work with the firm for, you know, one year, two years, three years. We get them to a point where we think, you know, what our, the maturity of our process is appropriate, you know, to the application that applications we’re building and the data that they’re processing. Uh, at that point, is it just some form of ongoing monitoring program or is it a once a year just check in? Or is it more that we’ve baked in some, uh, some operational components that would give us an indication if we started to lag from where we’re supposed to be from an SDLC perspective?
Sebastien Deleersnyder (28:37):
Yeah. And, and, and that’s actually what, what, uh, what you see here, it’s, it’s like with, uh, when you, when you deploy software, it’ll also evolve over time in terms of risk profile, in terms of vulnerabilities have been discovered in the wild. So you are actually never done, uh, with an sdl, uh mm-hmm. <affirmative>. But once you are at the point where you want to be, you need to keep sure, uh, to keep monitoring it because your teams will change, your application portfolio is going to change. So you need to make sure that you, that you, what you’ve learned that you keep doing this in practice again and again,
John Verry (29:14):
Right. Cuz your, your threat mo your threats are, are, are ever changing, right? Yes. You know, the minute that you have a new customers, the new contractual obligations. Yeah. New data types, new laws and regulations. Um, so speaking of new laws and regulations that ties into this, right? And the fact that we’re increasing reliant on third party libraries, right? As we build out applications, um, in the US you might be familiar with the framework and NIST 800 dash two 18, you know, know some people refer as the secure software development framework, which is being pushed by the US government. Uh, one of the things that it, it requires, right, is, uh, a, a software bill of materials, right? Software composition analysis. Um, so how does, um, how does Sam, one of the nice things that I like about the 802 18 is that, uh, it, it paid homage to sam, right? It’s heavily cross reference. So, uh, explain to folks how people can leverage SAM as they’re pursuing 800 to 18 conformance mm-hmm.
Sebastien Deleersnyder (30:10):
<affirmative>. Yeah. It, it, it’s great. Uh, and it’s great that as ISD f uh, has leveraged Sam, it, it’s actually, uh, has, uh, was doing or has done the mapping on the previous version of some, so the 1.5, and we are in the, in the process of aligning the mappings, uh, between SDF to, uh, to the latest sum version 2.0 Excellent. Which will probably release in the next couple of weeks, if not, uh, in January. Um, but that’s, that’s how, uh, how I, what we are working on right now. Um, and the, the, the great thing about some is that it’s a maturity model. So, and, and that’s where we see the, that where we can help an, an organization that’s already doing some to map that on, not only on sdf, but also on other, uh, on other frameworks as well.
John Verry (31:02):
Gotcha. Uh, speaking of other frameworks, any other, any other particular frameworks that, um, you care to mention? Some folks will ask me, uh, you know, what’s the difference between SAM and BBC as an example?
Sebastien Deleersnyder (31:14):
Yeah. And so it, Sam and BBC have the same origin story. So BBC is, uh, I would say yeah,
John Verry (31:20):
It’s a, isn’t BBC of Fork or didn’t they fork at one point? They were originally the same, same standard,
Sebastien Deleersnyder (31:25):
Right? They, they, they really started as being the same, but BC involved more on, on, based on digital and synopsis customers later on where they did surveys on what they were doing, where Sam was more, more like was a community driven, more prescriptive, uh, model than, uh, than BCM is. Um, but surprisingly one of the frameworks that we got out of the survey last month, or well, standards actually that, uh, people want to align some with is the ISO 27,000 series. Um, also majority of the survey responders, uh, were based in Europe, uh, where ISO 27,000 certification, uh, plays a lot. Uh, and a lot of organizations see this as a, as an their ISMS information security management system, uh, of, of choice, but then want to slot in some as being the component to use for, for the AppSec uh, implementation. So that’s where, that’s where we see quite some alignment. Also, with the latest, uh, release of 27,001, the, the 2022 version, there’s more focus on opsec. Uh, so aligning it with that is, is something that we see, uh, we see a lot.
John Verry (32:35):
Uh, yeah, I, I would agree completely. Um, you know, know we do a ton of ISO 27,001 work. It’s really what our, our calling card, if you will, we’re most known for. Uh, and a lot of our clients are SA app SaaS organizations. Um, so that, that natural alignment, like you said, between Sam a svs and ISO 27,001 just makes a, a ton of sense. Yeah,
Sebastien Deleersnyder (32:58):
Indeed.
John Verry (32:59):
Indeed. Gotcha. And is that something that you think that, that Sam is going to actually grow to, to specifically cross reference?
Sebastien Deleersnyder (33:07):
Well, yes. So, um, what we’ve done is, uh, we already have some, some mappings in the, in the past, uh, but what we’ve recently added to the SUM website, so if you, if you’re looking for some owa, some.org, you have the model in there mm-hmm. <affirmative>, which you can browse. And now for each of the of those, uh, in each of those security practices, we’ve now added links to guidance. Where there is links to Owas projects is Owas projects, uh, mappings to other, uh, I would say maturity models and standards, uh, but also best practices, uh, both within an outside owa. So we’ve bootstrapped that with, uh, a couple of like, uh, the basic OWAS projects mm-hmm. <affirmative> and some, uh, some starting, uh, guidance that we think is, uh, uh, is necessary. The good thing about some is that we’ve already, uh, we’ve always crowdsourced from our community is that you can also add your own or propose your own guidance, uh, as part of oam. Uh, we facilitated that with a couple of really easy forms that you can fill in and you’ll get feedback from, from the core team and, and it’s going to be included in the overall guidance.
John Verry (34:17):
Awesome. Um, I think we beat this up pretty good. Anything we missed? Anything you’d like to cover?
Sebastien Deleersnyder (34:24):
I think we’ve covered most of the important things that I wanted to cover.
John Verry (34:29):
Well, I wanted to say thank you, uh, specifically to you, uh, for the work that you put in in o osp. Uh, anyone who knows me knows that I, like I said, I think I’m a NASA fan of oas, been highly appreciative of all the work that it’s a volunteer-led organization. Most people don’t realize that, uh, you know, I’ve been lucky enough to talk to a lot of you guys, Andrew and Daniel Cuthbert and everybody else, so I know how much time, energy, and effort that you guys put in, of your personal time into these projects. So, uh, wanted to say thank you, not only for coming on today, but thank you for all the work that you do on our behalf.
Sebastien Deleersnyder (35:03):
Thank you, John. And I also want to extend that, um, that gratitude to, uh, towards the rest of the Sam team as well. So this is by no means a one man show. We have a big team that’s, uh, that helps, uh, push, uh, some forward.
John Verry (35:17):
Cool. Uh, so I always, uh, ask, uh, give me a fictional character or a real world person you think would make an amazing or horrible ciso or if you want to say application security, uh, professional.
Sebastien Deleersnyder (35:32):
I haven’t thought about this before, but, uh, a fictional character
John Verry (35:37):
Or real world,
Sebastien Deleersnyder (35:38):
Or real world, uh, maybe I, if you’re familiar with Garfield, the, the Lazy Cats <laugh> that will be make a very horrible season.
John Verry (35:48):
<laugh>. Why? Because he likes lasagna. So here’s the comical thing, Sebastian, I’m gonna embarrass the hell outta myself. In college, I was, you know, I used to love Garfield. I mean, like, I literally had every Garfield comic. It was one of my favorite comic strips, and my grandmother thought it was very cute, and she bought me a Garfield comforter that was designed for like a six year old kid. And I was a, a, a sophomore in college. My mother was beside herself, like, oh my God, thinking that I was gonna embarrass my grandmother. I thought it was awesome. And I brought it to college, and I slept <laugh>. I slept my last three years in college with a Garfield. And it became my, it became like my calling card. People knew about this Garfield thing. And then, uh, you know, uh, if someone was gonna give me a gift, like a girl was gonna gimme a gift, she got me like a little Garfield stuff. So like, I graduated college with like dozens of Garfield animals and all kinds of fun stuff. <laugh>. So, do I know Garfield? Yeah, I know Garfield. Yeah. <laugh>. Uh, so I was gonna say, is it because he’s fat slovenly and likes he too much lasagna? Is that, is that why you say he wouldn’t be a good
Sebastien Deleersnyder (36:55):
Yeah, it would not move forward, that’s for sure. <laugh>.
John Verry (36:59):
Yeah. And what was his dog’s name? O odi, right? ODI or Oden. Odi,
Sebastien Deleersnyder (37:03):
Yeah. Yeah.
John Verry (37:04):
So
Sebastien Deleersnyder (37:04):
The dog. Yes.
John Verry (37:05):
All right. Well listen, man, this has been fun. Thank you very much. If some folks wanted to get in touch with you, what’s the easiest way to do
Sebastien Deleersnyder (37:10):
That? I think the easiest, my email, I do read email, so it’s zeba first for characters of my first name at Oor, uh, [email protected] if you want to reach out, uh, professionally. And you can also find me on LinkedIn with, uh, Sebastian.
John Verry (37:26):
Sebastian. Thank you, sir. Appreciate it.
Sebastien Deleersnyder (37:28):
Thank you, John.
