OWASP Security knowledge Framework
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Part Number | 19 | |
| Number of Parts | 29 | |
| Author | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/18839 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
Hacktivity 201519 / 29
1
4
6
17
00:00
Software frameworkWhiteboardSurvival analysisCoordinate systemTwitterInformation securityTransportation theory (mathematics)TelecommunicationSummierbarkeitEmulationTopological vector spaceDecision tree learningInstant MessagingInformation managementStorage area networkSpecial unitary groupMetropolitan area networkPhysical lawSoftware engineeringWechselseitige InformationArmConditional-access moduleBus (computing)Hand fanUniformer RaumWeb pageValue-added networkMIDI19 (number)FreewareSoftware testingMereologyComponent-based software engineeringSimulationCondition numberInformationKey (cryptography)World Wide Web ConsortiumSelf-organizationOpen setSoftwareComputing platformComputer networkChecklistFormal verificationStandard deviationLevel (video gaming)Data typeSoftware developerImplementationPhase transitionCodeDemo (music)LoginOrder (biology)Function (mathematics)CloningComputer-assisted translationNetwork topologyEinstein field equationsElectronic data processingAcousto-optic modulatorRow (database)AreaMaxima and minimaArc (geometry)Indian Remote SensingFinite element methodLaw of large numbersGamma functionEwe languageWeightSigma-algebraMulti-agent systemUniform resource nameLaceUsabilityCapability Maturity ModelWater vaporSet (mathematics)RankingSoftware protection dongleCore dumpPiForm (programming)Execution unitMiniDiscSineWide area networkAuthenticationElectronic meeting systemPointer (computer programming)Term (mathematics)Lie groupComputer-aided designWitt algebraTunisRaw image formatElectronic mailing listPasswordComputer fileExact sequenceSystems engineeringExpert systemMagnetic stripe cardModal logicSatelliteCycle (graph theory)Video gameSoftware repositoryStatisticsHill differential equationSystem callChi-squared distributionCASE <Informatik>Wage labourVarianceMultiplicationAuftragsspracheSign (mathematics)State diagramSession Initiation ProtocolBuildingOvalNormed vector spaceGraphical user interfaceMathematicsLevel (video gaming)Software developerCore dumpCodeSurvival analysisSoftware testingCycle (graph theory)Information securityCondition numberSoftware frameworkWater vaporMereologyCASE <Informatik>InformationSoftwareConnectivity (graph theory)Formal verificationAuthenticationTelecommunicationExtreme programmingProjective planeChecklistPasswordContinuous integrationType theoryCartesian coordinate systemInjektivitätComputer filePhase transitionForm (programming)Expert systemStandard deviationImplementationFunctional (mathematics)WeightDemo (music)Execution unitSoftware repositoryWeb 2.0Electronic mailing listVideo gameSystem callMathematicsLoginCross-site scriptingNP-hardError messageMultiplicationAuthorizationWave packetBit1 (number)Connected spaceCommunications protocolShared memoryContext awarenessEmailGame controllerRight angleSensitivity analysisSelectivity (electronic)Metric systemPoint (geometry)Field (computer science)Loop (music)Goodness of fitCrash (computing)Electronic program guideDifferent (Kate Ryan album)Revision controlValidity (statistics)Insertion lossPairwise comparisonTraffic reportingFeedbackSingle-precision floating-point formatArithmetic meanLine (geometry)Multiplication signData managementDataflowClosed setoutputFlagSheaf (mathematics)Drop (liquid)Proper mapException handlingService (economics)Moment (mathematics)WebsiteStack (abstract data type)Content (media)Fluid staticsOnline helpWritingResultantLibrary (computing)Cross-correlationOcean currentPattern languageQuicksortDivisorWeb applicationSocial classSpacetimeMedical imagingINTEGRALKnowledge baseElectronic visual displayGradientLanding pageRadical (chemistry)Group actionMehrplatzsystemAnalytic continuationAsynchronous Transfer ModeVirtual machineLocal ringUnit testingOpen sourceCentralizer and normalizerVisualization (computer graphics)Capability Maturity ModelView (database)Server (computing)Process (computing)Software bugInteractive televisionTouchscreenComputing platformOpen setDescriptive statisticsDot productHookingDynamical systemTopological vector spaceVector spaceDiffuser (automotive)Procedural programmingData storage deviceHacker (term)PlanningForcing (mathematics)Uniform resource locatorMeasurementStructural loadSelf-organizationInternet forumFamilyDecision theoryMatrix (mathematics)Java appletFactory (trading post)Speech synthesisTwitterFile formatSurfaceChainInstance (computer science)Covering spaceComplex (psychology)Student's t-testSource codeData miningCryptographyHTTP cookieLogicState of matterAlgebraic closureRow (database)Generic programmingSquare numberPrice indexInformation privacyPersonal digital assistantSolid geometryExistential quantificationBit rateSymbol tableComputer wormPhysical lawComputer-assisted translationBranch (computer science)
Transcript: English(auto-generated)
00:00
So, yeah, I'm really happy to be here and, well, explain more and use the aviation as a comparison to the whole security and software development. So, yeah, survival is not mandatory and, yeah, the Air Force One has departed and are you on board? So, later on, in the end, we will come back to this question and, yeah, dive into it.
00:22
So, let's see, who am I? I'm Glenn Tecate. I'm a security dude at Schubert Phyllis. I'm also the author, together with my brother, of the OWASP Security Knowledge Framework. Well, here are some coordinates if you want to contact or have questions.
00:44
So, yeah, I want to start with airplanes. I mean, I'm personally really scared when I first went into an airplane. I mean, you give out the control, but, again, it is really a fast mean of traveling, right? It also is really cool. It's using the latest technology.
01:02
It has auto-pilots, a lot of cool technology in there, monitoring, communication, and, yeah, in my opinion, they are very reliable. Like, if you take a bike or go walking, there's a higher chance you will die, right?
01:20
So, yeah, I want to dive into the whole aviation and airplanes and to see how they handle, well, problems, how they deal with risk. And I think it was a really good comparison to the whole software development part and security. So, in the airplane aviation world, you have a lot of training, of course.
01:46
Training is essential when creating new pilots and, you know, teach them all the things. And, as you can see, they have to know a lot of things before they even can start, right? The instrumentations, the automation, all the stuff.
02:02
So training takes a long time and it's really a profession, right? It is part of the whole, yeah, not the development cycle, but the whole cycle of the aviation and getting pilots to learn the experience and the things they shouldn't know.
02:20
So, and the other thing is checklists. They use a lot of checklists. Before they land, before they go, they check everything because, yeah, you don't want to have an airplane drop out of the sky or lose the airplane that costs billions of dollars. And, oh yeah, there's also people in there. So, hey, let's check, check, check.
02:43
So checklists are really important for the aviation and the air pilots. Also, you have a lot of manuals. I mean, when there is a critic situation, they can grab the manual, go to the specific point in there and have some guidance on the issue, how to solve it. If an engine fails, what is the next procedure?
03:03
What should we do, right? So also manuals are a part of the whole flow of the aviation. Very important. Then, of course, you have testing. They test everything in very in-depth fuse, right? They really check like tubes, what is the diameter of it, how strong is it, how many bar it can resist, right?
03:26
So all the parts of the airplane are really tested in-depth. Like you see here in the picture, here you see they pump water into the engine because, yeah, there is a use case when you're in the sky and there's a big storm.
03:42
The engine shouldn't, you know, drop out or fail or go off because of the amount of water being pumped into the engine. So in here you see it being tested properly to see if it's handled correctly. So they do a lot of testing, like the critical individual components, certain conditions that are really rare, right?
04:05
Manual testing, of course, and in here you see, well, automatically testing. So testing of all the stuff, all the components and how they work together are really important. Also, I think this is a very important part, sharing information.
04:21
So the airline companies, when they found something and that's really an issue, like possible to let the airplane crash or, you know, they immediately send this information around, also to the other aviation and airplane manufacturing to see if this problem also is in there, right?
04:40
They really have a close connection together and, yeah, learn from their mistakes and trying to share this knowledge to the other ones so, yeah, they can keep their assets safe, and keep our lives safe, right? Not letting the plane crash. So in the end I see this as all this is for the good of protecting us,
05:02
for protecting the airplanes, protecting the people. And I really like this idea, this open-mindedness towards each other, helping, because, yeah, it's a win-win for everybody if the airplane keeps in the air, right? So now I want to make the step to the software development world.
05:23
So I want to start with how important it is to do security. I mean, last year, this year, around 45 million web applications got hacked, and these are only the metrics we know of, right? So 45 million that were open about it, like, hey, we got hacked.
05:44
So we don't even see the rest that didn't get reported, right? So also a lot of sensitive information is leaked, well, correlated to the airplane industry, lives of people are at risk, and, yeah, also criminals got really better in IT,
06:02
and heck, you know, and I see IT is still behind. So, yeah, the title says that those who fail to learn from history are forced to repeat the past, and, well, it's an obvious loop in the image, so, yeah, we have to learn, we have to adopt, we have to share knowledge,
06:26
like the aviation industry is doing. So then I come to the point where the sharing knowledge, the sharing knowledge I see is in the software security world, OWASP.
06:41
OWASP, Jim already mentioned it a little bit, is the open web application security profit, worldwide nonprofit charitable organization, really focused on proving security, helping developers, helping the world to do security right. So it is really a knowledge sharing platform slash network
07:00
for everybody is interested in doing security proper, and, you know, want to have guidance with it. So, again, I like the OWASP. It is like doing the aviation part, sharing the knowledge. It is a win-win situation for everybody. Also, OWASP use checklists like we see in the aviation industry.
07:24
So OWASP has the application security verification standard. That's the worldwide use checklist. It is already like five, six years old. We are now at the revision of 3.0. That is going to be released like yesterday.
07:42
Wow, okay. So yesterday the new version of the ISVS checklist came out. Like I said, this is really worldwide already accepted. And it is all about securing web applications in depth. Yeah, of course, you can visit OWASP for more information. So what is the ISVS?
08:02
It is the verification standard. And not only that, you can also use it as a security requirement. Depending on what type of application you want to defend, you can say, okay, the security requirement can be a level one for really easy simple web applications or a level three for really critical applications.
08:22
And depending on what level you choose, the different type of security controls will be in there. So what does it mean if you don't have security requirements? Well, in my honest opinion, it can only lead to one thing. In this case, in aviation, an airplane can crash, right?
08:46
I mean, the only question is when? If we don't deal with security and we don't have security requirements, this is reality. People's lives are at risk. So now to the good part, training.
09:01
Also, OWASP has a lot of training capabilities. Like I said, I am the author of the Security Knowledge Framework. It is really a tool intended to help and guide developers and train them. It is fully open. It is all about creating web applications, security by design.
09:20
We also make use of the ASVS as the post-development stage. And again, also we try to map and learn from the aviation. I mean, I have a really safe, good feeling when I get into an airplane and I know I get there. I get from A to Z and I land safely.
09:43
So training in here is also very important. Now I want to talk a little bit about the Security Knowledge Framework. So in the Security Knowledge Framework, we have multiple core functionality like the pre-development phase, post-development phase, the Security Knowledge Framework
10:01
as a reference for looking up things because what we found out when you are in desperate and you want to have some guidance on specific how to do or implement certain type of functionality, it is still hard to find a really good place where there is an authority and you can trust or, you know, it is validated once you look there.
10:25
And it was really hard because, well, take for example, cross-site request forgery. If you Google it, you get tons of examples and of those tons of examples, only like three or four are really good. They are really security by design, thought about it.
10:40
They didn't miss any implementation errors. You know, they thought of it very well. But if you were unlucky and you choose one or the others, yeah, then you implemented a weak cross-site request forgery. So the Security Knowledge Framework want to address this issue. They want to, you know, create a global place where you can look up the information, get guidance
11:02
and also is a place of authority, right? Because it is transparent, it is open source, everybody can review, edit or make, you know, contributions to it. And we also have the security code examples. Those are really intended to help the developer on a really implementation level.
11:23
And the code examples are not meant to copy-paste. They are all about getting the right mindset to empower the developer to create defensible web applications that are really secure by design. And with the security code examples, we try to give more guidance in depth
11:40
about the whole mindset that a developer should have, right? So now I want to have a small overview and look at the Security Knowledge Framework itself. The Security Knowledge Framework is basically a web application that you can run in on your local machine if you want that.
12:03
You can also spin it up as a service inside your company and use it like that. So let me swap here.
12:23
That's the open demo. So everybody can have a look, everybody can inject. We also have that. So if somebody now tries to inject the application, it will go lockdown mode. So please don't. So basically this is the landing page of the Security Knowledge Framework.
12:42
This application you can also run, like I said before, as a service or local on the machine of the developer. This is the landing page. And as you can see, we have a certain type of things. So I want to start with the knowledge base. The knowledge base is basically what all the other things are built around it.
13:01
So the knowledge base are like almost more than 200 items that you should take into consideration or implement in your, well, maybe critical web application. So as you can see here, it's very extensive and a really big list. So if you have a critical web application,
13:21
and, you know, that really is critical, you should implement all those checklist items. But have a look how many it are. So again, so the whole idea of the knowledge base is to have a central place of reference where you can look something up. So in here you can just say,
13:40
I want to know something about uploading, and then you get the file Upload Injections. So the knowledge base is basically explaining what the attack factor is of this item. So what can an attacker do when you have file Upload Injections? And as you can see, we don't bother showing how the developer can hack or do this.
14:01
No, we were just creating awareness and a mindset. Also, after that one, when we show what the attack factor is, we also have a solution. And in the solution, we want to guide the developer and tell him what are all the possibilities to really mitigate and, you know, stop this type of attack factor.
14:23
These knowledge base items are then also used in the pre-development phase and the post-development phase, but I will show you that in a bit. Then we have, like I said before, the code examples. We do have, like, PHP and .NET examples. We are working on the Python and Java examples.
14:42
And in here, we can have, again, a more in-depth view on how to approach this type of functionality. So, for example, this code example is about PHP file upload. A PHP file upload can be done in, like, three, four lines of code.
15:02
Then you have the functionality, then you have the file upload. But if you don't properly build this functionality, an attacker can easily own your server by uploading his own code, run it, execute it, and, yeah, you pwned the server. So in here, we have the code examples where we really want to guide the developer
15:22
on an implementation level and create the right mindset to how to approach this. So, for example, in here, we start the validation class. We start the logging class. Then we check the image. We select the upload there. Then we have, well, we tell about what do we check,
15:41
so we do an input validation. And, again, input validation is really important because those metrics we can use later on in the application to make the application make decisions, do proactive counter-measurements or all that type of stuff. Then we continue after the validation.
16:01
Then we do and handle the whole functionality. But before we do that, we're gonna log that we're gonna do this. So sometimes you have an application that does an action, and it does the action, and after the action, it does the log, the logging, the action. But what would happen if the attacker did a successful attack?
16:20
Then it probably never reached the logging functionality, and you wouldn't know that there's something wrong or somebody tried to attack you. So also in here, we have, I don't know, it's very visible, but... So the comment says, set a counter. Remember, if counter hits three, the user session must be terminated. After three session terminations, the user account should be blocked
16:41
since the high threat level will lead to immediately session termination. So when you have really critical functionality, you really want to punish that user. You want to use the validation to log, increase the counter, and say no. If you are doing bad stuff, move. So here, this is a good example how you can use your logging and the audits to prevent and do proactive counter-measurements.
17:04
Well, then we go further. We do a location. If the check's not correct, we do the upload, do the type checking. When it's successful, we log that also, right? And then we continue. So as you can see, it's really about
17:21
getting the right mindset and how a developer should approach it. Yeah, and like I said before, we also have it for .NET. So also here, you can have a look. File upload. So yeah, basically that are the reference part, right? If you want to have a specific question
17:40
or want to have on-the-spot information about a certain subject, you can use the knowledge base or the code examples to look it up. But that's not the only thing the security knowledge framework is for. We also have the ability to create projects. And in this project, you can see
18:00
I already created one. We have the ability to use the pre-development functionality or the post-development functionality. The pre-development functionality, that is basically what a developer would use when he's in the sprint or when he's thinking about use cases. So you have to develop
18:21
a new type of functionality and in here, you can put it into it. So even before you write a single line of code, you get awareness by using the pre-development tool. So for example, I can say here, I'm going to work on sprint 2 and I'm going to add upload functionality.
18:41
So now I can select multiple types of function and basically this is the technology stacks or the functionality a developer is, you know, common and it's often being used. So in here I can say, well, we're going to do something with forms, we're going to do something with the upload.
19:03
Let's see where it is. Yeah, file upload. Well, we're uploading so maybe it's also nice to do the file download. So now we can add those type of technologies and functionality to this pre-development phase and now we can say, okay, this is the type of functionality we want to
19:22
deliver for the next release. Then we can click here to do and view the results. So what happened now is the security knowledge framework made a correlation with this type of functionality to the knowledge base item in the security knowledge framework. So for example, the file upload, what type of attack factors do you have there? Well, the file
19:42
upload injections. And again, you see the whole knowledge base item in here. So before the developer starts writing code, he's already aware of the attack factors that are lurking around the corner for him. So for the file download, you have the reflective download and the file download injections.
20:02
Same for forms, you have a sort of pattern. You cannot only do and say like, oh yeah, you have to do this for a form. No, there are multiple things you have to do to make really a good form and submission. For example, simple single user input validation controls and all that loss. You have to get your cross-ride request forgery tokens
20:21
to spec. The principle of loss privileges. You have to use get slash post. So if you are doing data mutations, you have to do it always by post request. A good example of the OAuth, they are using get. So everything is leaked in the browser, in the log, etc. So these are all type of things a developer should take into
20:41
consideration. And like I said, it's telling him upfront. So even before he writes a single line of code, he gets this feedback. He can also download the report as a docx where all this information is in and share it among his colleagues or team.
21:00
So basically, the developer has this feedback. He goes and builds the functionality that was desired. When he created the functionality he wanted, then we got in the post development phase. The post development phase is the place where we created all the code and we want to do the verification if it's all implemented correctly.
21:23
And for that, we are using I hope it's still readable. We are using the ISVS, the OAuth application security verification standard. We do have split it up into level one. Level one is very nice if you want to start. You don't doing any security yet.
21:42
I would recommend start with level one. But for this example, this demo, we will have a look at the level three. Let me see. Is that a little readable? Yeah. So basically, this is the ISVS project of OWASP. And as you can see, it is a really, really extensive
22:02
checklist for helping developers doing the verification. So this part only is about authentication verification. So as you can see, there are a lot of security controls items in there. So let's say 15. Then you get the next section. It's about
22:22
session management. How to do proper session management. I mean, if you would miss or not do one of those, your whole session management design is flawed. If you forget to set for example, the how to pay only or the secure flag on your cookie, on your session cookie, you can do all this stuff and I still, or an attacker can still exploit
22:42
it and, you know, beat the whole purpose of it. So access control, malicious input handling, crypto, the error handling and logging, data protection, communication security, the how to pay protocol security, malicious controls, business logic, and false
23:02
resources. All those checks are helping, you know, to do the verification for the developer. So how would a developer use this? Basically it is an expert system. So it is basically using this security controls as a question and if the developer says, well
23:22
yeah, I thought of it, I checked it, I do it by this, it's all good. He can select yes, I'm good. If he comes to an item and he didn't implement it, verify all password fields do not echo the user password when it's entered, so in this case, he's like, oh shit, yeah, I'm sending the password through an email. It's like, oh yeah,
23:42
then no, you didn't correctly implement this security control, so you leave it on no. We also have the information box, it gives some more context about the checklist you're verifying, so again to help him understand him better what is required. Basically the developer will do
24:02
and fill in the whole checklist, then safety checklist and what the security knowledge framework has done now, he has correlated all the items that were selected as a no and correlated those to again knowledge based items to help the developer, making him aware hey, you didn't implement this security
24:22
control, so what is the impact? What can an attacker do? What are the attack factors? So for example, the first one verify all password do not echo the password when it's user has entered, so prevent password leaking, that is the security knowledge based item, this security control is correlated to.
24:42
So again, you get a description of what is possible for an attacker, and again you get a solution on how the developer should approach it. At the dots over here, this is determining the level of the ASVS item it's coming from, so you also know if it's a level 1 item or a level 3, like really critical
25:01
for high critical applications. And basically again, this can be shared, this can be shared among the team and help the developer empower him with knowledge and make it really aware that what the
25:21
possibilities are, we don't implement security controls. So basically those are the type of core functional entity when you're using the security knowledge framework. What I do personally is the post-development phase, I sit together with the development
25:41
team and really do like an extreme programming approach, like get them all in the room, put the code on the beamer on the big screen and really go through each item on the code level and try to, well, I try to challenge them, so did you thought about this or when I do this, did you
26:01
and then we go check the code, do the implementation, check all the security controls and it will take me like a day, day and a half to really fill in the level 3 checklist, right, because it's that extensive. So that's really yeah, in my experience it creates a lot of synergy, I mean
26:21
I learn a lot of those developers, I'm also developed by heart, so you get this nice interaction of sharing knowledge and you know it really is nice, it gets a nice atmosphere. So basically that was a little demo of the security knowledge framework and now I want to
26:41
go into the next level. So, you know, having the security knowledge framework of having security requirements, that is basically the first step, right, in the whole software development life cycle. So you still have to do manual things in the software development life cycle, by example using the security knowledge framework, filling all the questions,
27:03
right, but also you want to do code review, if you have critical functionality like a login or a password reset or whatever, you want to do a code review, the four eyes principle. Of course you want to use the static analyzer security tooling, right, so the
27:21
bid checkers and I don't want to know any vendors, so SaaS tooling. Then you have the dynamic version of it, so that is for example the Zop proxy, that is really a dynamic application security testing tool. It can be run automatically, that's true, but still you have to manually validate all the findings
27:40
that will pop up. And of course at the end of the whole thing, of the whole security development life cycle, you want to do a manual pen test by an expert and why is that? Because those are the experts, right, they can then do advanced stuff, not focusing on call site scripting or you know the low stuff, but really the advanced edge stuff.
28:02
So always do a pen test by a really expert. So of course we also have a lot of possibilities to automate things and the things we can automate we should do, right? So what made my life really easy when developing the whole
28:22
security knowledge framework is having automation, continuous integration so we can do deploys whenever we like or multiple times a day and still get the quality of code that we want to deliver. So for example we use in our software development life cycle
28:40
of the OWASP security knowledge framework project itself, we use three types of continuous integration tooling. The first one is Travis, coveralls and scrutinizer. So Travis is basically sort of a Jenkins, it's a built street, right? What happened is you can hook Travis up to your GitHub,
29:02
when GitHub has a change it will notify Travis, he will see it, pick up the new code and try to run it. Run it as in spinning up an instance, putting your code there and depending on what your Travis file is, it will do build the project, verify if it's still correctly being set up and built
29:22
all that stuff. Then you have the coveralls. The coveralls is basically, that's happening after the build, after Travis. When Travis is all successful, you don't have any syntax errors, the project is still running and installing, then it's time to do the coveralls. And coveralls is basically getting the metrics
29:41
from the unit testing and display it in a very nice manner. So the idea is when the developer does a commit and he passes the build on the Travis but maybe he changed code and then some type of functionality fails. The developer can then see, because it's continuous
30:01
integrated, after like one and a half minute that some of the unit tests fail, so the percentage of the whole coverall metrics drops instantly. So it is a really good feedback visual loop for the developer to see, oh, I killed some functionality so I have to relook at my code and see where I messed up.
30:22
Then the last part is the scrutinizer. And basically the scrutinizer is the code quality checking tool. So what it does is when the first Travis was successful, when the coveralls, the unit test was successful, then the last part is the scrutinizer. And what this does is it will analyze
30:41
the code on quality level. So do you have any dead-end code? Do you have any duplication code? Do you have any really complex if-else dead-end, blah. That is adding to complexity, but that's also decreasing the maturity and the quality of your code. So again, with this
31:03
continuous integration service, when a developer does a commit and he created sloppy code or dead-end or duplication code, the grade of the project will drop. And now we have eight, so if it goes below the eight you definitely know and see the impact of the commit you have
31:21
done. So now I want to also show a little bit about the software development lifecycle and show you the different services. So in here, this is the place where the security knowledge framework is placed.
31:41
Everything is in here. So for example, all the information, the code examples, all that stuff, you can just look it up here, click it, it's all in markdown format, so if you want or see any bugs you can really easily modify it and then push it. So for example,
32:01
let me add something here and commit change. So what does now happen is I made a modification Travis will notice and pick it up that I did
32:21
a different new code being pushed. And as you can see here, it already picked it up. So Travis now sees, hey, something changed there in the GitHub project. I need to revalidate, recheck if everything still works. So this is basically an automatic process
32:41
that happens every time I do a commit. It also works when somebody's forking this project in their own repo space and will also have all those benefits. It will do the integration on the Travis part. When that's correctly being built, then it will do the unit testing, and when that's
33:01
done, it will decode quality. And it's all independent of the main branch, right? So really cool that everybody then has this support and continuous integration. This would normally take about two and a half minutes to rebuild the whole project, set it up, install
33:21
it, and to see if there's any errors in it. If that went all correctly, it then creates metrics for the outcome of the unit testing. So unit testing produced metrics and those metrics you will see back in here. And again, so it is
33:41
very obvious if you forget or break a functionality because the display and the graphics will immediately show and give you the feedback, hey, something is wrong, go fix. And then, of course, at last, then we have the scrutinizer, and as you can see here, it will give you a grade. So if somebody
34:01
again, puts very bad or not good code, you will see immediately that he made a mistake or that he didn't add the right quality of the code. We can have a look at, for example, this one. This has a D, and it was already gone. But again, so if you
34:21
would click on the grades, you get the feedback of why it is getting this grade. And again, so you have the feedback loop that is very short that really helps the developer. So when I was talking, it now successfully ran the whole project, did the setup, tested, went all
34:41
well, no extra code. Then we go to the test phase and we run the test and then we will see that all the unit testing was correctly. Then we push the metrics to the coveralls, what we are seeing here, and in here when we refresh it, we will see update, code example,
35:01
file upload by blah blah, and we have still the same coverage. So hey, I didn't miss or break any functionality. Then over here, same again, we will do the scan and we will grade your code. So if you go back to the main project, over here, you have all those project status details.
35:21
And this gives me in a one instant overview what the status is and the quality is of my project. And when you have a lot of contributors, you really want something like this, right? It also helps, takes away time from the developer so he has more time to do security, right? That's what we want.
35:42
So again, it's a really short feedback loop that is really valuable for developers. So yeah, like I said, we did the whole aviation example, made the comparison. So what would happen if
36:02
somebody would say this to the president for his Air Force One airplane? Like, yeah, it's not necessary to change, it's not mandatory, and then I mean, come on. So I think we should take lessons from the aviation, work together.
36:21
If you have experience, if you have knowledge about security, please help. I mean, we're all in here to make it a better world. It's all win-win for everybody. If you would like to help the security knowledge framework, please do. If you want to help the other OWASP projects where you have a certain type of experience build up, please help.
36:41
I mean, we're all in it together. I also use the same airplane you're all going to use, and I'm also going to use all the services you're all going to use. I mean, it's all heavily connected right now. This is the moment to step up or we end up like the airplane that's coming down,
37:01
So yeah, basically that was my talk. Are there any questions? It was a lot of information, and it's not only about doing security by design, but it's also about the whole process, about the whole software development lifecycle using integration tools.
37:29
Well, it would be really nice to have more code examples, because on the level of the application security verification standard, that's really cool, but it is more generic way, right? It's just words.
37:42
And you still can have the awareness that you have to do something, but on the implementation level, there are so many things that go wrong, and that's also what you show with the OAuth, right? So yeah, I would like to have more code examples that help and guide developers and empower them with the knowledge to
38:01
really create secure web applications. So yeah, if you can write Java, Python, that stuff, please help. If you're really good at content and written it nicely, also step in or help. Check the OAuth site. There are tons of really cool projects
38:20
that are adding value. For example, the OAuth dependency check. It is a static analyzer tool that is finding all old CVEs in libraries or whatever, and every time I run that project and that tool, I found like 150
38:40
vulnerabilities, known CVEs in current projects. It's like, what? So again, have a look at the OAuth site and maybe the security knowledge framework and step up and help us help yourself, right? One more quick question.
39:01
Has your boss, Frank, over at youbert Bill, has chilled out at all, or is he still a spaz? He's chilled, he's chilled. He's a relaxing guy. He's also an open source visionary. He created the Secubus tool, for example. We are all in the same mindset over there and really want to add
39:20
value to the world and make it available for everybody. So yeah. Thank you, Glenn.