The Security Table
The Security Table is four cybersecurity industry veterans from diverse backgrounds discussing how to build secure software and all the issues that arise!
The Security Table
Should #AppSec be Part of the Development Team?
The big question is if it's possible to lose the application security team and move all the functions directly into development.
What are developers' roles in application security (AppSec), and what challenges do they face? We delve into developers' responsibility in ensuring security, despite not always having the necessary tools or training to do so effectively.
We discuss "shifting everything left," which refers to integrating security earlier in the development process. We express concern that developers are being burdened with increasing responsibility without being given the power or resources to handle it effectively. This is referred to as the "inverse Spider-Man thing" - with great responsibility should come great power, but this isn't always the case in AppSec.
FOLLOW OUR SOCIAL MEDIA:
➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel
Thanks for Listening!
Hey folks. Welcome to another episode of the Security Table. name's Chris Romeo. I'm joined by Matt Coles and Izar Tarandach. And. I don't know, recently it feels like we've been talking about lots of reasonable application security things. I don't know. This seems like it could be in the realm of reasonable. gonna dive right in and just read the question because this has already been referred to by my colleagues as a grenade in the room. That, that, uh, maybe into our conversation. And so that question is, should AppSec be a separate team or should the responsibilities of AppSec be completely owned by development?
Matt Coles:he's not gonna use it as an air sickness bag.
Izar Tarandach:Go,
Chris Romeo:that bad of a question. Come on. It'd be, even if it was popcorn, it'd be better. So, but it, but it still works. Matt.
Matt Coles:All right. So the, the quick, the quick way I want to intro, wanna start this conversation if it's okay. Is asking, asking this, asking this back to you, do you consider quality engineering should be a part of development? Because it comes down to that, that this is ultimately, I think the root question here, should development own all of the functions that presumably provided checks and balances on their, on their activity?
Chris Romeo:Does quality engineering even exist anymore in 90% of the companies out there?
Matt Coles:Whether or not it does, the question should be, should it, and should it, and, and or is it being done by development today?
Izar Tarandach:in and everybody keeps trying to sell me this thing, uh, uh, test driven development and all that, that good stuff. So the, the quality is, the quality has gone much closer to the, to the developer, right. At least the quality of this thing that you just wrote, does the thing that spec needs says that it should be doing? My point is that,
Matt Coles:Yeah, unit testing and whatnot.
Izar Tarandach:agree that security is a feature of quality, we will always be coming back to the point of who watches the watchers, and if the developer is doing the security testing now. Not only is the testing being done right, the, do they know what they need to test for? Is the test valid? are all the proper edge cases, uh, addressed? So I hear a lot of people complain to me that as a developer, they find themselves writing much more tests than code. And now we want to overload that with, uh, uh, security tasks. Which is an area where developers, at least my experience, is that developers feel much less equipped actually do that testing. And the question, am I doing the right thing, is much stronger than am I doing the reasonable thing?
Matt Coles:A, and we already know that the testing that is required for security tends to be very cumbersome and, and in addition to challenging.
Chris Romeo:I'm, I'm a bit concerned I think Izar just made an argument for compliance
Izar Tarandach:No, no, no, no, no. that,
Chris Romeo:Now let me, let me, let me read back what
Matt Coles:Where's, where's, where's, where's that jar? Where's the, where's the, where's?
Chris Romeo:heard you said. I don't quote cause I can't remember exactly, but you said something to the effect of who's watching the watchers should security be able to do their, their testing?
Izar Tarandach:So
Chris Romeo:And so to me, I was, I was like, should developers be, you know, who's, who's watching over the developer's shoulder
Izar Tarandach:no, no, no, no, when I said, who's watching the watchers is the developer watching themselves, so I, I haven't touched in security at all. Like I, I'm looking, if we the developers, will that ever be enough? So, yeah, I, I totally see where, where, where you went of compliance. I, I, I see where you got it. If, if I went, if I had gone,
Chris Romeo:I was afraid I was, I was afraid.
Izar Tarandach:gone to the side, but, but, but look, that, that's the big problem that we're trying to solve, right? Why, why are we. Bring the jar out again. Why are we trying to shift everything left? Because we want security to be less burdened by the day-to-day stuff that we say we can scale because we never have enough, uh, uh, security people and is the security gap or myth or not and blah, blah, blah. And we go back to the roots of, of this PO podcast, right? But. What I'm trying to say is at, at some point we, we, we push stuff on top of developers and push and push and push and push. And it's not only a workload, but we are also pushing, uh, uh, uh, responsibility because we keep saying that developers are the gatekeepers of security they want or if they don't, they factually are.
Matt Coles:Okay.
Izar Tarandach:My point is that, and, and we have addressed this a number of times, we, we don't train people sufficiently or well enough. We don't cover in training everything that they actually need. yet we keep asking them more and more and more and more and more. And, uh, it's, it's, it's sort of like I, I keep asking you, asking more from you, but I'm, I'm not giving you the tools that you need to go there. And if you have those tools, I'm not giving you the time to use those tools enough and so on and so forth. But I think that what I'm trying to say is, in an ideal world, Where security was completely as a factor of quality, and we could trust that developers had enough knowledge and enough, um, enough, uh, uh, to do the security right thing. Then we would be freeing the security team to do those things that are at a higher conceptual level, like figuring out the next step of what could possibly go wrong or to free them to create more tools, to do more testing that would validate all the controls and all the, the design, uh, stuff that we put in. I just think that we are not, that we are very far from that ideal world. And at this time, to say developers be responsible for the whole security cycle is premature. And more than that, it's, it's unfair to all involved. would create an expectation that we could never fulfill.
Chris Romeo:Hmm.
Matt Coles:It. So just to summarize, I think what you've said, cause we've, we've touched upon this in other, other episodes, right? We are, what we're talking about here is giving developers more responsibility. Making them accountable for things without giving them more capability. Right? So they are, we are asking them to do more without giving them the ability to do more. And, and so that brings a challenge. The other piece about, you know, the, I, and again, back to this notion of, and whether security is part of quality. I always use, I always use making them equivalent. Not necessarily that they have to be a part of, um, but. You know if, if developers are writing code and developers are testing code, and developers are testing security of that code, and TE developers are releasing that code, so two pieces. First off, they are under pressure from their. You know, their organization, their leadership, whatever, to, to release something that functions on a schedule. And so there's a pressure from, from that respect that what, what loses in that conversation, right? What's the first to go? If they're responsible for everything and they're under the pressure to release, and, and I'm not saying that, that that solves it by having AppSec outside of their organization. But having an org, having parts of the parts of the broader organization that have the ability to pre press the brakes right. To, to reveal that there are, well, alright, it doesn't always work, but the goal is, the goal is that somebody, so there is, there's a organization outside, whether it's a quality organization or a security org, or a privacy org. Or legal or whoever it is to say, uh, I have some concerns, and oh, by the way, here's, here's the things that you need to consider
Chris Romeo:Is
Matt Coles:in that, in that aspect,
Chris Romeo:where we have this? Challenge
Izar Tarandach:the thing.
Matt Coles:no,
Chris Romeo:like
Matt Coles:I don't think so.
Chris Romeo:cuz you're describing governance, you're, you're describing a need for the governance function. So even if we pushed everything into development, we still have some check and balance of governance. But, so, so I can't, like what other parts of the business other than security have to have a governance angle
Izar Tarandach:So
Chris Romeo:that requires somebody else to audit and, and look at what's happening.
Matt Coles:qual in, in pro in product development. That's qual quality Engineering does exist if you're talking about product, product development, physical systems, especially more so than obviously cloud services whatnot. Sorry, Izar, go ahead.
Izar Tarandach:are talking compliance again or governance, and it's not, it, it's, it's one step before that. What we're talking here is, is verification, because now we were putting the, the developer a responsibility that needs to be verified before it gets accepted, right. So it, it's,
Matt Coles:Well, actually, wouldn't you even go further back than that? Sorry. Is there, um, An AppSec program doesn't start with verification.
Izar Tarandach:start with, bring that whole thing, that whole load to the developer right now, okay. What we are left with at the AppSec team side is to have that verification so that you ha can have assurance, so that you can have governance, so that you can have all that good stuff. So,
Chris Romeo:Yeah, so verification is governance though. Like we can call it verification, but it's, it's governance. At the end of the day, it's did you do the things you were supposed to do, and are there any glaring issues that came out of it that you refused to fix?
Izar Tarandach:when we say governance, it has a, weight of being a security thing by itself. I think that what I'm trying to say is if we are bringing security to the developer, as again, the analogy that I always make the same as performance, right. You don't really have like a formal verification compliance assurance thing. Performance is just expected
Chris Romeo:Mm-hmm.
Izar Tarandach:and if it doesn't, we will notice because something is going to take longer than it should. Oh, no,
Matt Coles:may have performance metrics that you're, that you're working towards.
Izar Tarandach:to stand by that threshold that was specified, right. So it, it's interesting that now you can think of security in terms of, okay, do we have a threshold for security that we have to stand by? And then we go back to reasonable security. All, all, all things lead to reasonable security nowadays. But the, the, the interesting thing is that the interesting to me thing here is that it's one of those, those cases of, actually, let me put this the other way. When, when Matt was talking and he mentioned the, the, the pump, the brakes, Immediately What, what came to my, my, my mind was not exactly a car pumping the brakes, but all of a sudden we, we are putting developers in the position of solving the trolley problem, right? They, they're coming down the street in this trolley, and there's a fork in the road, and they can decide which side they take, and one side is performance. One side is security. Where are you going to put your time? Right? You're going to, you're going to kill
Matt Coles:right. It's exactly what I was highlighting. Yeah.
Izar Tarandach:So
Matt Coles:right.
Izar Tarandach:I think the developers today are better equipped to choose the performance usability feature branch than the security branch, and they will by default choose that one because there is this function of some form of AppSec team that's going to take the, the load of going to the other branch and doing those specific things.
Matt Coles:Do you think that champions embedded within development teams help, help address this in some way? And actually should we consider champions as being an extension of AppSec in the development organization? Given the champions generally, uh, may or may not be writing code may, it may not be building features or working on performance. Also, in addition to security work.
Izar Tarandach:I will tell you with full mouth But have seen the light and I have been led to to think in other ways that a proper champion program
Matt Coles:talk to.
Izar Tarandach:will make all the difference. having a security champion, probably not having a proper security champion program behind that security champion. Probably yes. Is it going to solve all the problems? not. So it's going to make life easier for everybody? Yes.
Matt Coles:Yeah.
Chris Romeo:it
Matt Coles:So there you get. Okay. Chris? Yeah.
Chris Romeo:you don't know what you don't know. Like champions provide visibility into more of the problems and issues and things that are taking place, and it, it, it is a connective tissue kind of thing between the development teams
Izar Tarandach:Yes and no.
Chris Romeo:to.
Matt Coles:Mm-hmm.
Izar Tarandach:I think that rather than visibility, they, they provide a filter. I think that again, in a good Security Champion program, going to get a level between the development teams and the the AppSec team where the things that are going to reach the AppSec team are those things that the champion was not able to deal with by themselves to an unacceptable level. you're going to get the more hairy things.
Chris Romeo:Yeah. So filtering from a good perspective in that the champion will be able to deal with some things that never bubble up to the AppSec team
Izar Tarandach:I would go one step further that filtering is mostly going to be what people in AppSec teams would consider noise filtering. Don't come to me with your injection. Come to me with your big, big, big, hairy problem.
Chris Romeo:Mm-hmm.
Matt Coles:Right, so, so this is an interesting, let's bring it back to the topic at hand. Now imagine if that champion was working for himself. I. Because AppSec is now part of the engineering team. So we're not talking about taking and extending AppSec into development. The question is, should AppSec be part of development? So what do you lose in that situation? Let's say for a moment that you have an engineering organization that's split across multiple, multiple units. Who gets who gets what? Airtime. Right. You have, you have a, I imagine you'll have challenges of, of domain control across your leadership, right? People with different reporting structures. Unless you have a unified engineering team, you're gonna have a, uh, a, a play at back and forth, right?
Chris Romeo:have to see the, like peop engineering leadership has to see the light of the importance of security, the prioritization of security to your, to the earlier points about at the same level as quality and performance. I, I think you can, I think this is the goal. I think this is, this should be where we're aiming. I don't think we're there today. I don't Most mat, most organizations are not mature enough for engineering leadership to be responsible for the application security of the things that they build. Now. I think it's a good thing to get there. Like I, my, when I think about this question's, like in 10 years from now, that's not the question, but I'm gonna change the question. In 10 years from now, is it po, would it be possible for AppSec to be owned by the development team? Yes, because we're seeing tooling, security tooling should become development tooling and any anybody that's building a tool out there, if you're not building developer tooling as an AppSec team or as an AppSec, if your products aren't migrating towards the developer and they're stuck on the security team, you're gonna be going out of business in the next
Matt Coles:Can, can I, can I just jump in though? There's more to AppSec. There's more to AppSec than verification. There's more to AppSec than even development,
Izar Tarandach:the
Matt Coles:right? AppSec includes, but uh, hold on, hold on. So, if. And I think, I think I'm, I'm correct here that AppSec would include requirements and, and good thing we're not talking about privacy, cuz there would be a, a, a plethora of those things to worry about. But let's say, you know, security for a moment has to deal with only a handful of, of require of, of standards and basis of, of requirements. They have to do translation from industry requirements into product requirements. That's so requirement. Generation in the first place is not a gentlement task today.
Chris Romeo:though. Like in this new world,
Matt Coles:Right.
Chris Romeo:should be the ones that own. So if we're gonna have AppSec be engulfed by the engineering department, requirements management has to be engulfed by the product management
Izar Tarandach:Mm.
Chris Romeo:function.
Izar Tarandach:But by putting it that way, you get to a position where in a, in a, in an extreme situation, you could have a project manager saying, you know what, guys? Forget security. We, we have all their stuff to deal with. Right? I think that in the case where becomes a development function, call it requirement. Call it, uh, uh, uh, Stuff written in stone security has to become a value, something that the developer wakes up and aims for, today it is not
Matt Coles:Mm-hmm.
Izar Tarandach:okay.
Chris Romeo:Well, I mean, in product management, your example about product management is that, I mean, I, that, that would be my old school answer from the days of days gone by. Oh, well, product managers aren't gonna promote security. They're not gonna, they're gonna say, we're not doing security. We have a customer feature to do. don't know that that's still the case though.
Izar Tarandach:that's the thing. It's not the case. It's not the case. But given the choice, as Matt said, given the choice, something is going to give it's human nature. And if,
Matt Coles:Yeah, time pressure. iron
Izar Tarandach:and
Matt Coles:triangle of program management, right.
Chris Romeo:but are you gonna give up
Izar Tarandach:a new feature
Chris Romeo:in this day and age if.
Izar Tarandach:and adding security is delaying product going out of the door. choice is going to
Chris Romeo:And a, and a and a CVSs 10 Vulnerability is me losing my job as a product manager in this new world.
Izar Tarandach:but then they go and find somewhere else security is not of value.
Chris Romeo:Yeah, I mean, if security is, if, if you're, if you are, if the of a decision results in people getting fired. Which I've never seen that happen yet. I haven't seen that in my career yet, where, where a product manager is held accountable for a I'm just saying I don't think people are as naive about security they were when I was in a big product company.
Izar Tarandach:not.
Matt Coles:And we should keep in mind that the, the executive order, so the things that are coming out now from cisa, from nist, the executive order, et cetera. Are starting to bring this to the forefront. Right now, the people responsible and we in, in order for a moment of who actually is responsible, but the people who now, who are responsible today, now have to take it serious or have always had to take it seriously, but now actually have a, have a financial penalty for not doing so.
Izar Tarandach:point. Why are we as security professionals so happy that all this stuff is coming out? we are seeing the shadow of the big stick in the sky coming everybody. now,
Chris Romeo:Yeah, but remember
Izar Tarandach:aside
Chris Romeo:this is,
Izar Tarandach:see, we told you you'd better do this stuff.
Chris Romeo:but remember, all of these documents are only governing sales to the government, the US government.
Izar Tarandach:still a, a big
Chris Romeo:It, it, it, doesn't,
Izar Tarandach:power. Right? And at some,
Chris Romeo:but I don't, yeah, but I mean, how, how big of a buying power is it at the end of the day? Like, it's, it's, I don't.
Izar Tarandach:we discussed this, at some point politicians will say, wait. Why only the government is being asked to do this? Why isn't
Chris Romeo:Yeah, but they've never done it. They've never done it in, in, I've been in this industry for 26 years and I've always thought that, and they've never done it. whatever reason, they have not been able to capture the private side because that's a whole new era when we're getting into the Geopolitical podcast now. But like that's a whole new level of government oversight and control. That one stifle, I think we talked about this before too, stifles innovation in my mind, anytime the government comes in and says, here's what you have to do, innovative people just stop doing innovative things and they, they fall into a world where, Least common denominator. So I don't, I, you know, it's interesting that it's never happened in, in the 26 years I've been in security. I always thought it was, I always wondered why the government didn't mandate requirements for security for every, every product that's created in America. For some reason they haven't, I don't think they're going to.
Izar Tarandach:let, let's do the methane and bring this back to the initial question. So you say if government starts putting Rob. rules into place and expecting people to abide to them, then that's going to kill innovation. What happens when we bring that, that down to the scale of development team the government, in quotes, being the AppSec team, putting down rules that now they have to abide to. Will that kill innovation as well?
Chris Romeo:That'll kill everything. be the end of the technology sector, what you just described.
Izar Tarandach:so the answer, so the answer to our.
Matt Coles:No, no, no. I think he's making equivalency, not, uh, not the government being part of
Izar Tarandach:the answer to our question is no.
Matt Coles:Right.
Izar Tarandach:team still needs to exist and have a function that's not going to be fulfilled by developers, because otherwise that's going to kill innovation and, and, and kill all the good stuff that they do. And I don't think that that's the answer that we all agree is the right one.
Chris Romeo:I mean, I don't see how lack of an AppSec team kills innovation. My point is, anytime you governments Kills security. Yeah, yeah, yeah, yeah. I mean, well, I mean, but does it though, that's that, but that's what we have to try to understand. Does it really? I would've said 15 years ago, yes. If you remove the security team, everyone in development would be like, ah, we're free. Everyone we're doing, all we're doing is feature development for the next six years, but I don't know that that's still the reality of the way product managers and engineering teams view the world.
Izar Tarandach:and I would say it depends, right? Because again, remember when a couple of episodes ago we said, Hey, security is not a constant, is a function, right? So be some environments where the lack of an AppSec team coordinating things, and at the most basic, like. Different development teams and you, you, you are drawing a, a bar of security that everybody, a minimal bar that everybody has, has to stand to. That, that, that's a central function. There's no way to have teams collaborate and, and figure that bar by themselves that there must be a not easy. Right?
Matt Coles:Not easily. Yeah, not easily. Yeah.
Izar Tarandach:guys in a garage with the startup understanding that all the, the stuff that they are using is off the shelf is. Cloud provider given the threat model is very well understood, and they know that in these guidelines here, if they follow these guidelines here, they they'll be fine until it's time to get more complex so that that security function. One of the things that it's pointing to at the graph is at which step do you forcibly need an AppSec team in place?
Chris Romeo:But in a perfect world, going back to the kind of the beginning of your example here, wouldn't you want is now the planning piece of the AppSec team in a perfect world, doesn't that exist in whatever planning in engineering? Versus having it as separate, a separate planning and management kind of function of, of what we're gonna do. Like when I come back to it, I'm like, if I was gonna design an organization from scratch and there was no other constraints on the way people perceive I would put the pieces together. program management would, I'd have program management for engineering. I wouldn't have program management for AppSec and program management for engineering as separate
Izar Tarandach:what you, what you're saying now is perfect word, security has such a place in the table where it's not a separate function anymore. So the people who already have a place in the table that. Generally we have agreed these are the people with a high seat in the table. All of a sudden they do security as well. And you don't have the guy from Security City on the side and going, oh, but security. Oh, but security. So in a perfect world, yeah, but my God, we are so far from a perfect world.
Matt Coles:Yeah, and that comes back down to there's a quality team, right? I'm gonna go back to quality. Quality is a fun, quality is a part of that, has a seat at the table. They always do. Whether they're staff separately or they're part of the development team, there's always a line item In program, program planning. Where are we with quality?
Chris Romeo:I think, you know, we keep,
Izar Tarandach:it's sub intended because again, quality is a value. Security isn't.
Chris Romeo:but we keep coming back to quality as an example here, and I think. Quality as a function in a very small percentage of the technological world as far as companies and pro to Matt, to your earlier point, product companies, pr, large product companies is where you see quality specifically called upon,
Matt Coles:Define large. large,
Chris Romeo:greater
Matt Coles:uh, because.
Chris Romeo:than Did I call it greater than a hundred developers? Is where, or, mean,
Matt Coles:Okay. That's fine. That's fair.
Chris Romeo:bigger than that. I, I've, like, when I look at.
Matt Coles:I would say with a hundred.
Chris Romeo:I look at companies that I just don't see quality mentioned a lot of places that I travel anymore,
Izar Tarandach:from quality back to performance. Okay. To that goes into production and, and, uh, I've seen this a number of times. It's performing code. It can be crappy code, it can be really, really crappy quote, is it doing what it's supposed to do in the time that it's allotted to it? Yes. Ship it, So
Chris Romeo:Mm-hmm.
Izar Tarandach:code is code that gets shipped. Secure code is code that takes more time to get shipped today because of
Matt Coles:Today because of the way the product development or uh, co-development is done, right.
Izar Tarandach:my head, I, I keep going back to, I think that what we asking from developers now is the, the inverse Spider-Man thing. Like with, with great power comes great responsibility, we are asking them for a lot of responsibility without giving them a lot of power.
Chris Romeo:I like that. That's good. That's a whole talk. There's a right there
Izar Tarandach:wait, let, let me put
Chris Romeo:in that title.
Matt Coles:Yeah.
Chris Romeo:Add it to your list cuz that's, that's good. That is, that's, that's everything that's wrong with AppSec right now.
Izar Tarandach:you know, and, and we give them the, the, the power in very um, Small amounts, very focused amounts. We're giving them, uh, I don't know, code helpers in ideas. We're giving them Lins. We're giving them sca. We're giving them sas. I will not say desk. We are giving them, yes, we have rasp. And. We, we are put putting this load on top of the developer all the time, but we have to at the same time realize that each one of these things that we are giving them has a whole backend that has to be kept fed by people who understand security and not development. that, I think, is the final function of the AppSec team, which is to feed all these mechanisms of power that we are giving to the developer.
Matt Coles:Yeah. So one, one thing, and maybe, and this is, this is probably a good place to stop it. I'm gonna tee it up maybe for a future. Conversation, are we giving them that, of that capability or that responsibility, or are they asking slash taking
Izar Tarandach:Yeah,
Matt Coles:that responsibility?
Izar Tarandach:forcing on them because it's the way that we are finding to scale up the AppSec team that as we have agreed, we, we never can man enough. We never can person enough
Chris Romeo:I'm glad we got this all figured out. So the next 10 years of AppSec, it's gonna be easy for everyone. That's right. He has more, ladies and gentlemen, there's more popcorn to be eaten while someone else tries to make a statement. Like that's a, that's a thing. So, I mean, I think when I, when I summarize this, I think about AppSec owned by development or being integrated. I'm gonna say integrated is a better word than Owen. So, so AppSec integrated in development should be a lofty goal that we aim towards, I think that is the perfect state for. way these, for really optimizing and making things go really fast, having people having these two functions But Izar to your point, until we get to the point that the, the era where security is valued, it's, it's understood, non-negotiable everywhere. It's gonna be tough to, to not have a separate team that can do it, but we can aim in that direction.
Izar Tarandach:but, but notice that we haven't touched a whole different conversation that's connected to this. What happens when security becomes a function of development, you have a high rotation in your development roster. So that's one more part of tribal knowledge and, and culture gets changing all the time. And how do you deal with that?
Chris Romeo:it's, I think it's, it, it ultimately comes down to your development developer experience, right? That's a big thing now of, of having the right tools that simplify ramp up for new developers that. Provide the information that developers need to be the highest, you know, as productive as they possibly can, maximize productivity. And when we start thinking about AI coming into that, that's gonna be a part of developer experience as well. But, you know, if, if, if security is part of developer experience, then I think it, it helps to solve that problem that you're describing about turnover and ramping up new people. that's what I see in 10 years from now. I would be shocked. If developer experience wasn't fully in, including security and AppSec pieces all being fully integrated.
Izar Tarandach:same time, don't forget that on the side of the on the side of the experience, on the side of the culture and all that good stuff, we also have a lot of uh uh, Good advances the, the basics of the thing. Like for example, the adoption of rust Now in the Linux, Kerno, it's memory safe, but it is performance, it is on par with C and, and other performance languages. So that, that, that's a good one, Do, do, do.
Chris Romeo:Yeah, I 10 years you're gonna get a lot of improvements, right? Like the ecosystem, to your point, the ecosystem is gonna improve in 10 years as well. That will make this even easier to include in the developer experience. Like imagine a world where c. I mean, I don't know when we're gonna eradicate. C Eradicate means 0%, will be a day. There will be a day where
Matt Coles:We have assembly still in, in use. What? forget, forget seat for a moment now. But actually, and actually that, that's even, I mean, we can get into a whole, whole can of worms here. Like Kubernetes has, Kubernetes probably has to go, uh, if we're gonna talk about security, uh, right, because I mean, misconfigured mis misconfigured servers is a, is still a big problem. I, I believe.
Chris Romeo:about, it's more of an infrastructure problem. If we're doing away with the AppSec team, we don't have a team. There's no AppSec team that,
Izar Tarandach:or is that a DevOps problem?
Matt Coles:Uh, that's an interesting
Chris Romeo:I
Izar Tarandach:talking security, Is that a dev sec sec DevOps problem? Like whose problem is it?
Chris Romeo:It's almost like this, it's almost like development and, and
Izar Tarandach:Oh my
Chris Romeo:are, are converging. I mean, when I think Kubernetes, I think about there is running Kubernetes yourself and there's Kubernetes that the cloud provider provides for you as a managed service that does insulate you from a lot of the, the shooting yourself in the foot of things.
Matt Coles:I, I, you know, I find, I find it astonishing that, that you are so divorced from product development, physical things that ship to customers, that contain a plethora of technologies. it's like you're, it is like you're enduring an entire, like half the population, I mean, Seriously, the world is not all cloud yet.
Chris Romeo:It should be. Why is it not all cloud?
Izar Tarandach:His savings for a cloud today for Yeah. So where are we on time today?
Matt Coles:give you, give you, give you one power failure, and you'll know why the whole thing can't live in the cloud.
Chris Romeo:doesn't fail.
Izar Tarandach:is perfectly re uh, uh, redundant.
Chris Romeo:Now we're gonna start talking about reliability. So, all right. I think this is, uh, I think we, I don't know. I feel like we made a little bit of progress on this. I, I think it's, it's there. There's nothing to be done. Well,
Izar Tarandach:agrees.
Chris Romeo:all in favor.
Matt Coles:There we go.
Chris Romeo:Our, just, just to let everyone, if anyone else ever listens to this, that is our one audience member.
Izar Tarandach:And the
Chris Romeo:And uh, the dog can only hear Matt's portion. So very, the dog is very against
Izar Tarandach:No, no,
Chris Romeo:and I in anything that we say cuz can't hear.
Izar Tarandach:He's getting the whole
Chris Romeo:Oh, good point. Good point. Well folks, thanks for listening to another episode of the Security Table. Um, we'll bring another challenging question after Izar is raising his hand.
Izar Tarandach:we finish that, we have to put, put a call out here. folks, were listening to us. As you all know, the three of us are big fans of threat modeling. And we are coming up, we, we are part of the, uh, beautiful brain that's thinking up the threat model con. At the end of this year, we are looking for submissions conference.
Matt Coles:Conference conference. Not a, not a, not the other. Con
Izar Tarandach:Now it's a conference and we, we are looking for, uh, uh, submissions, papers, and stuff for you to present. please look into our, each. Each one of us has their own, uh, social media presence. Take a look in there. We have made many posts and posts with the, uh, the pointer to the, uh, the cfp. And we, we really lo look forward to, to meeting new people with new ideas there. So even if you think that it's something crazy, and you know what, I'm gonna volunteer if you want to submit things, but you don't think that, uh, they're, they're ready enough or you think they're not good enough or anything like that. By all means, reach out to me and I'll be happy to work with you and polish that, that submission to the point that you feel good about it. uh, uh, we, we are expecting to hear from you guys,
Chris Romeo:All right, I'm gonna send my submission, oh wait,
Izar Tarandach:Oh, don't you have a keynote or something?
Chris Romeo:I might, I might be, I might have an opportunity to address our audience. So, hey, uh, folks, thanks for being a part of the security table again, we look forward to talking to you again soon.
