Climbing App Sec Mountains and How to Summit

thank you so much um i i really appreciate what it takes to put on a virtual conference especially when you weren't planning on going virtual so um i would like to you know extend a thank you to all the organizers because it's a lot of work first planning a in-person con and then transitioning uh to virtual only con but obviously it's for the better of the community so it's something that had to happen so thanks again uh my name is adam schall and today i'm going to be talking about climbing apsec mountains a little quick who am i side um i work for contrast security i'm a principal application security researcher uh there's my twitter handle and website

if you wanted to follow along with my work or follow up with questions after the talk um of course like our like our intro said uh um if you have questions during the talk feel free to put them in discord um i'll go ahead and follow up and i'll be in the breakout room after the talk so some of my hobbies include spending time with my family and my two kids they're told not to come in here but who knows we might have a visitor or two as it is with virtual conferences i enjoy home lab home automation i'm a colonel con board member which is a conference in omaha nebraska we also had to go

completely virtual this year so like i said i feel the pain of the organizers um and i enjoyed participating in ctf competitions uh a quick little inspiration about this talk um uh in the past i've worked for some huge companies big berkshire halfway conglomerate worldwide data provider cable services conglomerate all of these companies had um a huge staff spread of crap spread across uh spread across the nation and sometimes the world and um i worked at these places and i just got a feel for that large corporate lifestyle and did some application security i worked on some internal application security teams some internal software teams uh but now i work for um in a startup essentially

there was about 150 employees when i started we have about 300 employees right now but um it's just a world of difference and so it's really i was able to reflect back on my time at a big company and i was able to kind of uh come up with some some resources and some tips and tricks when you work at a big company like that and uh and develop this uh develop just talk so uh now you might be wondering why a kid from nebraska is gonna talk to you about climbing mountains but just wait it's going to make sense so uh first i'd like to introduce you to apsec ned um absec ned is just a he's a

application engineer he's a representative of many internal application uh security engineers into one easy to draw person he works for a large enterprise and he's starting an internal application security team at this large enterprise and he's happy that his company is prioritizing application security and like all good security personnel abseconned is on twitter so if you're interested in following along with his journey he he likes to make his way around the nation talking about the perils of creating mountains for your internal application security teams so uh but he had so when he joined the team he was given some directives uh and this is kind of generic directives given to all internal application security teams

uh first he had to ensure that all code bases are secure including all open source software utilized um he had to ensure all future development is secure uh and his board heard the term shift left with future development so they they made that a priority which is also a kind of a buzzword we'll we'll talk more about that later if you haven't heard of it but uh if you're in application security i'm sure you have uh he has to train software developers in secure coding practices and minimize attack vectors in external facing applications so ned has these directives given to him and but ned has some industry challenges right two out of every three applications fail to pass initial

tests on the os top 10 and the sams 25 standards that's incredible but 67 or more applications will fail on the initial test um the average time to remediate an application vulnerability is 171 days now that's the average there's of course outliers but that seems like a really long time that's over five months and uh one software security specialist to every 73 software engineers and developers so this is a number pulled from the bsim if you set behind one maybe even two developers and you watch them code all day to determine whether or not they're coding securely you could do that technically but can you imagine trying to sit behind 73 developers to watch them code

i mean that's impossible not to mention ned's team also has to review new library vulnerabilities and open source software vulnerabilities that are released every day these are some serious challenges also um all of the most common vulnerabilities over the last five years are still just as prevalent today uh these five vulnerabilities were the most common vulnerabilities in 2015 and they're the most common vulnerabilities in 2020. what does that mean well that means that our software teams aren't necessarily learning right these are typical mistakes that are still made today and if you have people who aren't learning or gleaning information from training that's a problem right we would expect that these would fade away in and

there'd be a new set of the next five top vulnerabilities that hasn't happened in addition to these type of challenges um also the typical application uh has a ton of challenges so in a typical application this is a this is maybe a little convoluted slide let me uh let me describe it here in a typical application uh 21 is custom code and about 70 70 is like is unused library code across 30 or more libraries that's the kind of code that um gets pulled in with a library and really just isn't utilized um so there's a big discrepancy between the custom code and the library code just in sheer volume and like you can see from the slide deck

uh the majority of the code is in the unused library code well also um over 70 percent of the code you ship is unused and only two vulnerabilities occur in there on average meanwhile 26 vulnerabilities um on average occur in the custom code so that is just adding more numbers to the mix here but that's 93 of all vulnerabilities that are found occur within the custom code so this custom code right here this top of the iceberg that's where you're going to get 93 of your vulnerabilities so this is another problem that ned's facing but ned really he knew about all those challenges when he took the job um he had some climbing gear so ned had

uh ned had some climbing gear that he knew about going into this job uh the workplace already had static application security testing or sas as it's known they had a dynamic application security testing or das they also had a web application firewall and they had a compliance team

into your network then there's a compliance team for auditing and penetration remediation etc so ned he felt prepared for anything you know i i prepared this slide before kovid but then uh during the toilet paper shortage of 2020 that we'll tell our grandkids about i thought this was a perfect slide

i'm being told that there's an audio glitch can people still hear me okay okay well uh just to sum up again ned had some uh hand-me-down climbing gear that the uh that the um company he's working for already had uh sast and das tools web application firewall and a compliance team for auditing penetration remediation etc so ned felt like he was prepared for anything um and so he felt good but you know let's talk a little bit about the state of application security especially at a large corporation uh there's a lot of hidden challenges i'm going to go back to the iceberg type slide here where ned is aware of the top of this iceberg basically

he's aware of some of the challenges but there's a lot of hidden challenges associated with working at a big company um including old tooling mergers and acquisitions new products and new technologies workplace shifts and inflexible developers so these kind of challenges exist um they're much more prevalent when you're working at a bigger company and i'm going to discuss each of these and how absec ned can overcome challenges like this so let's talk a little bit about old tools this is uh trigger warning for some people but um here's here's some here's a uh application security timeline and there's uh there's more uh to the right here and there's even more to the left but i want to focus on this time period

real quick um basically uh penetration testing uh became popularized in 1999 the owasp o wasp top 10 was formalized and introduced in 2001 but what else did we notice here um the four the four uh things that we just talked about as um as his climbing gear they're uh they're old they're more than 17 years old this is when they were introduced that's not to say that uh ned's team is using a static analysis tool from 2002 but technology uh hasn't hasn't been introduced from hasn't changed really since then there's there's been new stuff but ned's team is still using these kind of tools and uh this is 2002 to 2003 time frame and you know we're in 2020 so that's

these are old tools that he's using and what's what's wrong with old security tools as long as they're getting updates right well they can be slower they can be slower both with scanning and remediation i know for a fact that one of the sas tools i used at um i used at a previous employer uh when we needed to update the tool we had to contact our it because they owned the server uh and we didn't have permissions to get the machine key so they'd go and get a machine key for the server that it was running on then they would provide us the machine key we'd open a ticket with the sas provider they'd create the new sas tool uh keyed

with our machine key so that we can utilize it they'd give it back to us then we'd have to open a ticket with our ite support to install the new upgrade that takes forever and people were hesitant to jump on to upgrade these tools can you imagine how many vulnerabilities you might miss during that process you're waiting on people you're having to open tickets um by the time this all happened sometimes it took three weeks an update would come out and we would be updated three to four weeks later and during that time frame you can miss new vulnerabilities i mean just think about the last week uh anybody see the um show of uh emojis

on uh on discord but anybody see the most recent like um rces there was a f5 one a big ip one uh there was several within the last week in some big corporate type tools and if you're taking four weeks to upgrade your tools you're going to miss stuff like that and you're going to miss vulnerabilities another problem with old old tooling is alert fatigue uh tools were got really good at telling you when something could be wrong uh they got they never they never really learned um basically how to tailor those alerts so uh oftentimes with sas you you end up getting overwhelmed with alerts not to mention web application firewalls um web application firewalls

uh that's mostly just a regex search uh against the inputs and we're going to uh um we're gonna talk more about that but that really causes alert fatigue as well and they don't offer the best protection against attacks um this is uh like static code is essentially uh attempting to read your code and determine if there's a vulnerability um more on that later we're gonna there's a little foreshadowing so let's talk a little bit about mergers and acquisitions uh again i created these slides pre-covered this is an outdated practice now but um m a is a is a big part of big business if you work for a big company you can expect that there's going to be a merger or

acquisition while you're there it's a it's natural especially if your company is publicly traded um you know there's the famous quote by the microsoft ceo every business will be a software business and you've heard probably mark andreessen say uh software's eating the world right um every company is having have some they they all have some sort of software component to them now and when you're acquiring another company you don't know what you're inheriting uh it could be terrible software could be garbage servers etc and that's a major problem for internal application security teams i worked at a company that did mna and didn't involve the application security team at all and again that was the big

problem because what we ended up what ended up happening was we would inherit something and we'd have to spend you know a full-time employee essentially fixing their code uh because we just inherited somebody with uh you know 40 uh critical vulnerabilities including the most basic uh uh one or one sql injection like we inherited a company with a problem like that and so there was there was a lot of um heartache a lot of grief uh and this is this is a major problem industry-wide and when you think about application spread um large organizations they already have more applications than the industry and now they're doing m a to just add to ned's pile of ever-growing work

here's let me just uh let me just bring that in real quick here here's here's the differences right industry-wide so that means um organizations with a single owner to organizations with um thousands of employees five thousand plus employees look at the difference here uh the the numbers down here uh next to the color those are the number of applications that your company has industry-wide across the whole industry more than half of companies have less than 200 applications but when you are looking at a large organization with 5 000 plus employees the majority of those 36 have over a thousand applications i mean you're talking about time tracking software internal applications you're talking about external facing

websites external facing software every one of these applications is included in this and that's a huge discrepancy right uh when you're looking solely at a large organization and the majority of those have over a thousand applications that's a huge difference and now they're adding more right through mergers and actually mergers and acquisitions they're adding more company more software more applications and uh any when you're acquiring another company you're not adding just one or two applications you're adding their entire software stack now you know you're exposed in the entire way that they're exposed you know if they have a bad infrastructure you're you know that you're inheriting that we had um in my experience we had a spot where we

were acquiring another company it was a smaller organization and they were able to pass pci compliance through a self check because they were small enough when you're small enough you can basically fill out a worksheet and they'll say that you're pci compliant and we went and looked and uh they would have failed our they would have made us fail or our pci compliance so we couldn't acquire them until after we went through our pci um compliance audit because we would have failed so we had to finish our audit before we acquired this company because just by acquiring them we were going to fail our entire audit and then we had to go and fix all of their stuff over the course of

the next year and that's a challenge and that's a challenge for absec ned uh let's talk let's talk about new products and new technologies this is this is a popular topic because there's always something bigger and better and better and best out there um i mean let's face it software change is constant and i don't uh i don't mind that i mean that's that's a good thing we want software change to happen i mean it's usually for the better right just here i show like you've your agile um you've got your devops you have your microservices uh you've got your cloud providers uh azure gcp and aws you've got your uh continuous integration platforms like freaking jenkins uh git lab and

github actions um you have your containers kubernetes docker i mean these are these are all happening you know and things are just continually add to the software stack it's not necessarily a bad thing like i said these are great i love docker containers i love the ability to create my own app that just spins up in its own container and i can just kill it um whenever i need to i like continuous integration platforms these are these are good things but let's talk about the problem with that right so as ned is noticing here his mountain is starting to get a little bigger you know it started with the old tooling the mergers and acquisitions

and now new technologies um new products and new products and new technologies i mean what's the new hotness right um here's an example rust go kotlin right the funny thing about this rust logo is uh i don't play video games and for the longest time in the slide deck i had uh i had the rust video game logo until somebody somebody told me last week i thought that was pretty funny but um these are all these are all new hot languages right i don't want to discourage innovation but encourage consideration right um when you have these new technologies chances are ned's existing tools don't cover it yet right in 2008 i think is when go came

out and go is just starting to get wide acceptance into tools nowadays and it's been it was invented in 2007. okay here's a note i have it was invented in 2007 and it launched in 2009 as open source so it's been around for 11 years and tools are starting to just like have a wide acceptance of go for example so when a new language comes out like rust or kotlin i mean those two aren't very old uh you know how long will it be before we have tools that support that it could be a while right so again we're not discouraging innovation here just encourage consideration so we'll talk more about how we can handle that but

this is just adding to ned's challenges and these mountains are getting bigger and bigger and um ned was aware of some of the industry-wide challenges but these challenges at these big companies where it's the wild wild west and developers have the uh latitude and to just do what they want right um is just adding to is just adding to his um his stack let's talk a little bit about workplace shifts workplace shifts happen especially with time it's hard to ignore the facts but there are several kinds of workplace shifts or relocations um you know older developers retire or move into new roles layoffs i mean layoffs are a big thing nowadays too there's a when i'm on twitter there's a

lot of people who are looking for work um and that's that's tough right uh sometimes layoffs are even accompanied by overseas hiring so that that's why i didn't call this just uh just um workplace loss but i called it workplace shift because uh sometimes you have people going out uh sometimes you have people being replaced and and that kind of thing happens it's it's natural um you know it's a it's a crappy thing to talk about but um it's it's it's natural and it's even more natural at large corporations this is this is to be expected and um you know ned has ned has a problem with workplace shift right uh nan has to train new employees

uh sometimes in remote locations uh whether it be a time zone difference or a language barrier it's tough to work with new employees directly and how do they retain the knowledge of the departing staff how do we continue to meet application security standards when we have turnover in our own staff these are challenges that ned faces with workplace shifts what about application security secrets you know when you have uh when you have people getting laid off how does ned um ned has to concern himself with application security secrets um you know if we lay somebody off ned also has to worry about you know a disgruntled employee so these are these are things that you

know ned has uh to keep in the back of his head and and those mountains are looking big and he's looking nervous now lastly uh this is a topic everyone loves to hate but in flexible developers um i was a developer i was a developer for almost nine years so i have a lot of experience with development teams um and application security teams so what is an inflexible developer well um here's an example uh inflexible developers see security as a blocker right and uh and that's a problem uh security and tech debt will grow sometimes engineering fights to backlog security and sometimes findings are swept under the rug right if you give there's only so much latitude you can

give your developers if you give them enough permissions to um to ignore a finding or to claim that a finding is not an issue um is that is that too much latitude are they going to just say that all things are not issues right so this is a this is a challenge and uh there's a lot to consider here and that mountain is starting to look really big for app second ed he's starting to get a little nervous it seems impossible but um we're going to talk about how to summon right and and what we can do and how we can climb that mountain uh ned is uh apparently he's he's still at base camp so

he's having fun um like mitch hadberg says uh base camp is fun but ned has to climb the mountain so just starting out he has a lot of energy to tackle some of these big things again ned's directives he wanted to ensure that all code bases are secure including all open source software he wanted to ensure that all future development is secure and again his board wants him to shift left with future development he has to train software developers and secure coding practices minimize attack vectors in external facing applications these are all um ned's directives passed down from the board uh he you know he has his his industry challenges but then he also has to worry

about the challenges we've discussed building up this mountain basically that come along with being a big organization so let's talk about shifting left if you haven't heard this term basically shifting left is the idea that you involve security earlier on in the uh sd um the software development life cycle right sdlc so the idea being that uh the earlier you involve your security team in this uh entire process the better right and so here's here's kind of just uh talking about ned's environment in a lot of corporate environments here's kind of a typical setup right your software security scanning tools sit between tests and acceptance um you know pre-production and you're scanning and you're you know

you're cycling back from here back earlier on to the code phase and you're going back and forth here you have stuff out in production if you have a web application firewall i have yet to work for a company that had a web application firewall in block mode just sitting there in block mode because uh it was blocking too many legitimate requests most companies um have a laugh in a monitor mode and that is where it takes in logs and it's logging all the traffic essentially and then you have something on the back end tracking what a waf says is an issue and determining whether it is or not you have a person or you've written a program to parse

these logs but a lot of waffs are sitting there in monitor mode so this is a typical environment setup right here and let's real quick again the challenges are old tooling mergers and acquisitions new products and technologies workplace shifts and inflexible developers so let's let's talk about tooling right how can ned climb that part of the mountain here uh can newer security tooling really help with speed uh the answer is a resounding yes so i'm gonna introduce you to two concepts here and maybe you've heard of them but i asked and rasp are two of the newer security technologies is an interactive application security testing and rasp is a runtime application self-protection basically you allow agents to instrument

the code bases to both provide security against attacks and allow for more expedient remediation by pinpointing issues let me talk more in detail about that right with an is solution you can detect vulnerabilities with instrumentation to observe applications as they run during testing you can assess the security of code user interaction user interaction libraries frameworks back-end connections and configurations and essentially perform continuous and real-time application security testing throughout the entire life cycle this means that developers get immediate feedback and semi-solutions have route intelligence basically completely mapping each route in the application when you think about pen testing right there's the old uh there's the old routing um when you're when you're routing a web application backwards

right we're thinking okay what are my avenues of attack and how can i attack this application um and i and i ask solution routes it forwards so it routes the entire thing from you know from initialization all the way to all the different possibilities of of where inputs you know occur and what code touches what code and that kind of thing can really help when pinpointing issues and rasp is another popular modern application security tooling rasp can detect and block exploitation of software vulnerabilities basically it can differentiate between attack attempts or probes that can impact an application uh unlike a perimeter-based web application firewall uh let me give you an example of that here's an example right you have two

different inputs one is a your most common sql injection attack and one is your most common crosstalk scripting attack uh if this is your code where you're essentially uh setting a name right uh obviously if you're familiar with um with javascript this is going to result in a cross-site scripting alert it won't result in a sql injection you're not touching sql so in this case rasp actually instruments the code uh it sees this input it allows the input to go through but once it gets posted here back to the page that's considered a sync so it watches soars to sync and if something if an input tries to escape a sink boundary it will flag on it so in this case

a waf might block both of these because they both look egregious but if you are um if you are naming your team uh after little bobby tables or just having fun with an or one equals one uh in this case um it would be fine right i mean you have no problem taking this information and sticking it in as a name uh so uh rasp would watch this input and it would not escape the sink boundary and of course it would just paste it into the name meanwhile input number two here that's a problem and grasp would flag on it so that's why it can differentiate between attack attempts and attacks that have actual impact

right um it can also protect application runtime environments from unwanted changes and tampering uh and again we're tracing attack attempts from source to sync uh so here's here's kind of some stats to back this up right this is a um this is from contrast and vera code the percent of vulnerabilities closed within one month of discovery nearly 60 percent almost double of the vulnerabilities found with rasp tools are closed versus a sas tool and you might not say why is that well the reason is because rasp can more accurately tell you um exactly what the problem is and you have data to actually uh track source to sync uh and then also you close more

vulnerabilities with rasp faster i mean that's essentially what we're saying here uh rasp um has only 32 remaining after that three months of discovery remember at the beginning i said industry-wide the average remediation time is 171 days so after three months you know if you only have 30 percent left of your vulnerabilities you've closed 70 you're shortening that time that window which is great uh meanwhile sas still has over half their vulnerabilities have yet to be remediated after three months so as you can see definitely um using modern technology and modern tooling can definitely have a big impact on your vulnerability remediation so i'd like to propose maybe shifting out right uh where you're shifting left still

but you're also shifting right where you're moving some of your tooling into production like rasp uh you can also with with something like rasp it's easier to tune your waff into block mode right you can um you can remove a lot of the you can use a simpler rule set a more egregious rule set and turn it on into block mode and then rasp you know is also there to protect against stuff that isn't in your waf rules that and you can shift left and involve i asked in development right is going to provide feedback to developers while they're working in their ides and testing uh testing and routing their own code so as they're testing a

new feature you know you could get is feedback already so now you're now you're involving security super early on in the in the design phase but also in production right so you're shifting out um each way and you're there's um uh this can only benefit you so that feels pretty good about that and he's made his he's made some progress ned thinks that he has a good idea of where to go with old tooling um but he he still has a long way to go right he's this is i think a mordor uh from lord of the rings they got you know they get on top of one little mountain but they still have a

long way to go so let's talk a little bit about mergers and acquisitions uh in in my mind this is the most obvious solution but the hardest solution because you're essentially having to convince your executive level staff that you need to get apsec more involved in a m a discovery earlier you you heard me tell an anecdote about how i worked for a company where we acquired a um a company and didn't didn't even get to check them out until after we acquired them and had their software in-house it could only be positive if appsec is more involved during the discovery phase let's think about this right if ned discovers that something is amiss i mean theoretically you can use that as

a negotiation tactic your c-suite uh and your negotiators can lower total pricing if they say hey we're going to have to fix a bunch of your security issues this is a problem um also it's going to give ned the leverage to demand more head count if you think about it and if ned's team is able to identify security issues and it's able to potentially lower total cost then you um you have the ability to uh save the company money and and also tell them this is going to require more work so i need more people so and if ned if ned discovers uh uh nothing egregious then he can begin planning on onboarding i mean that you

know that'll at least give them a little edge on onboarding so uh overall you know this can only be positive because involving involving uh apsec is either gonna save you money or give net a jump start but you do have to convince the c-suite which is again that's what i found to be one of the bigger challenges but that ned feels like hey you know it if i'm he's able to talk to his c-suite and convince them using the the old adage that money talks um you know and and we're going to either save money or save time uh by involving my team so ned is not quite at the midway point but he's making some

serious progress now so let's talk about new products and new technologies how can ned contain this ever-growing landscape of products for developers it's sprawling right and it's not going to go well if you tell developers that you're taking away their ability to innovate right you can't you can't say to a development team like i'm taking away all of your administrative privileges because you you want to write something using rust that's terrible that like that's that'll weigh in later during this uh development apsec relationship you know uh again i want to hammer this point home we don't want to discourage innovation we want to encourage consideration so how can the appsec team work with the development teams

and and their managers in order to basically basically create an acceptable well to create an acceptable use policy here so uh ned is going to he's going to create this policy and it's and adding to it is easy but it needs to be reviewed by an enterprise architecture review board or an er um so essentially ned's going to go through and he's going to white list a bunch of technologies that you can use and if you want to add a new technology you just propose it to this eorb board right and uh the er board um basically their mission is to provide a strategic approach to innovate technology-based solutions by maintaining an optimal consistent set

of standardized best practices so essentially they want to review the new technology that you're bringing in determine if we have a solution where we can cover its security support it's the support its use and uh and they want to be able to accelerate the time to market on the product so this is something that's enforceable then by compliance and it's going to take advantage of that compliance team that i mentioned uh in the beginning as one of his uh is one of his climbing tools so the compliance will enforce this um this list but adding to it is easy enough so uh we want to again allow developers to innovate but we want to make sure that they're

aware that you know their innovation is going to affect the company in some way and so we need a team to review that if we check in on ned he has now uh he has now conquered three out of the five challenges let's talk real quickly about the workplace shift or the departed this happens it's not always fun and not always with much notice uh if ned doesn't have advanced warning of a relocation or layoff there's a few things that he can prepare ahead of time uh you may or may not have heard of burn lists uh basically uh it's a list of user accounts and where they exist this can be vast and take

a significant amount of time but the sooner ned can automate it the better so you'll want to make sure that you are aware of all of the user accounts that you're going to have to take you're going to have to remove the security operations are going to remove their you know their microsoft outlook access their vpn access but you want to make sure to also make sure to also remove any application credentials uh that they have also um this is an interesting one that not many people do i found a default credentials sweep uh i worked at a company in the early 2000s that has a default credential in their production environment so it's it's a credential that developers

use to develop uh and uh it's still out there so ned creates a default cred sweep basically ensuring that any testing credentials don't make it up into production so uh workplace shift um so what about new employees right i mean that's how to handle the departed and try to you know retain that um knowledge and worry about you know a disgruntled employee but uh what about new employees well ned has to use a training platform that works remotely and is easy to distribute it's important that any new employee go through secure software development training before they touch code so he makes it part of the onboarding process ned also creates documentation around standard best coding practices uh

this is something that um kind of revolutionized uh a company that i was working at where um his team stubbed out authentication session management api requests database connections and more like you just wrote code snippets that worked for this language that you knew was secure and is in common use so that team like let's say it's net right you write out a dotnet um authentication uh and a.net session management sub and your.net team if they're onboarding someone and they say like hey you need to add authentication just go over here and check out that stub that's already ready to go you can just go grab it so uh again i'm doing checking on ned ned's

doing great he's near the top of the mountain he's uh high enough to appreciate the view but not comfortable yet uh this is the big one right inflexible developers um application for that fighting engineering is a fight where everybody loses if you remember uh the old movie war games the only way to win the game is not to play so uh there are several things that can improve the relationship first off application security should be housed outside the engineering group either under a ciso cio or cfo you need to create a separation of priorities among engineering management engineers should not be able to say no to something that you deem a critical security fix it's also

important to reiterate that application security is a resource not a hindrance it's not a blocker after all your developers don't want to push vulnerable code application security engineers should have development experience in my opinion uh this this set the twitter world of flame when somebody tweeted this uh it was like last year but uh they think that you know application security developers in particular should have development experience um or extensive experience with code i think the best way to become an application security developer is to be a developer first and then you know gain the security experience and move into security and application security so uh why is that important well think about how you can endear yourself to

developers right you it should be a partnership between the appsec team and the development team um and think about ways you can you know endear yourself um training can be fun you could gamify competitions i've hosted ctf competitions for my development teams uh it can help bond each other uh it can help the dev team you know learn and um that you are an expert in your field uh you can do secure coding hackathons lunch and learn sessions q a sessions uh provide launch once a month uh joint outings include development and team outings i mean this is this is crucial right it's a partnership right it you should if you're an application team member

and you work with you know lots of developers in the same office post covid let's say uh you should be having lunch with them you should be seeing them on a regular basis making friends with them because working with working with people like that is going to make your relationship uh less combative and more of a partnership right uh ned happens to buy his uh he buys pizza once a month so man's over there eating pizza so if you look at uh ned he's he's um i think he's accomplished all his his directives right he's ensured that all current code bases are secure including open source software uh he's uh ensure future development is secure he's shifted out

with future development uh he's trained software developers in secure coding practices and uh minimized attack vectors and external facing applications so at this point ned i'm gonna call it ned's and then summited the mountain um i wrapped it up about 53 so i have about seven minutes for questions and comments please drop them in uh in discord and i'll answer them a german poster of the new guy uh believe it or not i couldn't find a good uh suited suitable for work poster uh from america so yeah it's a german one uh let's see open question what's the best rasp tool do you think is out there in your honest opinion also same with the i asked

tools uh well brian and wobblebox um i work for a company that provides both is and rasp and i work on the team that helps drive the um innovation and product so i don't think that's a very fair question because uh i'm gonna i'm gonna answer it one way and i don't want this to turn into a uh a product supported talk so i i know that rasp and is tools there are several out there i know that if you are looking at an is tool i would encourage one that does complete route intelligence because i think that that's going to provide the best coverage when you're looking at rasp tools i think that configuration

is important and i think that configuration is important and um and so i think that something that allows you to kind of uh tune your own rule sets is uh is important because um you're unique in business environment or your unique business unit uh is going to have different rules than you know somebody else's business unit so you're going to need to be able to say like this is important to me or that i want to put this into monitor mode or block mode kind of thing um i think that you're going to want something that's uh continually innovating and has future focused mindsets so i know that my company does that um but i'm not going to

you know compare with other other companies let's see uh yeah i said something uh i said someone's username i don't know if that was wrong any other questions yoga might help if you're an inflexible developer uh thanks uh panda i was wondering why they keep telling the apsec team down dog i don't know follow that mark uh feel free to clarify so uh any other questions um please drop them in uh in discord i've got a few minutes left here

okay well i haven't seen any any future questions i'm going to move to the breakout room i know that the next person probably wants to prepare so uh thanks so much i really appreciate it again thank you to the organizers of uh beside san antonio i really wish i could i could have visited san antonio for the first time but um maybe next year so thank you

you