Security in Continuous Integration and Continuous Development

First of all, I would like to welcome myself to this community event, this great community event, which we support a lot. Today we're going to talk about security and continuous development of the integration environment. Actually, the hard level of training in this area. A few things about myself. I am the manager director of WebSec. I've been a penetration tester for almost 13 years now. Not a like number. I am a SSP, CISP and all these other certifications that I can't remember. I'm not a developer, so don't expect from me very precise things concerning development, but I've been working with software development analysis quite a lot of time. And I am really here to help the community grow,

especially in the Greek FH security community. So that's why today we want to present you with the hard lesson learned when we faced for the first time and the times, a couple of times after that, a software development life cycle in agile, continuous development, continuous integration. So a bit of history. For ages, the developed model was the waterfall model. So the design, the analysis, the implementation, the test and deployment all was done in series. It took months to be a coderist, all years. So security had all the time needed in order to put processes into that, to put checkpoints, to do testing and deliver a secure product. The thing is now, with agile and cd and ci things have changed now we have very short

cycles two weeks in history where in these two weeks we do the design implementation testing the path fixing and the deployment so this means that every pull request goes through a pipeline of different quality checks security checks everything that the developers have been there and potentially and it ended up in the production department deployed at the end of these two weeks. So this design has not left a lot of room for security. I mean, when we first encountered, it felt something like this. So we see here a screen for Sata. He goes, after the sprint line, he goes into the application, looks into the architecture, looks the design of the application, waits for the code

drift and now the code is positive, you can do the code modeling, you can do source code review, you can do penetration tests, you can do all this time, all this together, he finds a security issue, he makes an application, he disapply, now the code is free of security issues and the value. All this in two weeks. So you can imagine it's very hard for us and we start to think outside of the box for that. So we have here the traditional sprint cycle. Again, the developers in the audience may disagree that this is not the only thing that happens in the sprint cycle, but these are the things that are discussed about this talk. So we have the design phase

where everybody is gathering the sprint plan to session. They decide which future they're going to be playing. And they push them to the backlog. Then we have the three amigos meetings, which are a developer, an analyst, and a tester. And they all agree how the feature is going to be implemented and how it's going to be tested later on. So before the development begins, the developers know what kind of test we are from a functional point of view. Then the implementation phase where they develop the features, then testing with unit testing, mode testing, BTT, protractor and so on, automating and manual functional testing, but fixing the doyment. All these in two weeks. So what we did? We tried to put our

processes into this time frame, some of them and some of them out of the time frame. The first thing we did to put into the PNW3 is the design review from a security point of view. So after the split planning we do workshops with the lead developers in order to identify how they will implement the features, advise them on the implementation, identify any ASV controls that should be in the feature and put them on the definition of damage. So that means that the developer cannot complete the task of developing this feature without implementing security. Then we went into the three amigos we did and we made it four amigos with you. So now we have a security persona there, which gives feedback on the scenarios that depend on the

feature from the security point of view. And most of the times, we create our own security scenarios. This is done either in the community language or in the scenarios or whatever The development team is used in the red logic. The next part is the source code review. So what we did is we put specific trickets on the pull request. So each pull request, we check the code. We are part of the quality review team of the source code. And we check the data flow that is the one that's supposed to be there. We just get the top 10, the start 3.25 run abilities, specific technology type lines and of course all the other elements that are there and they are

not in these guides The next one is automation. In CI and CD automation is key because you don't have too much time to do money at this, you have to automate every kind of automation and we do that with scripting we don't like it, nobody likes it but Sometimes we don't do it any other way. We use BD security from Continuum security which is a framework that helps a lot to the base of the same potential test processes. Of course, for tackling and in-capital care, we face angular, or other client side technology such. And we set up a bird switch camera with specific extended modules for a specific application. For each feature that is released, then we do a penetration test focused on this

feature. You don't have time to do penetration tests in full in the application or in the weeks. We try to have a different person do the penetration test from the Wawa Dittas to Scodium view. So we have four eyes visible. and we do the penetration test for the security screens which I will talk about later so now the initial sprint cycle comes like that on the design we have the ESPS controls mapping and the design review from the security point of view we do the for apping those meetings we do the source code review due to the implementation on the blue request and the penetration testing on the

So now the security screens. We realized that you cannot fit everything into a normal development screen. So what we did, we planned security screens, one, every major release. So every backlog that we have from security should have been identified that they were being low or we don't have time to fix them. We fix them at this moment. We do architecture review. We improve our automation. We are the scenarios that we have missed during the original screens and we do a full scope for integration and evaluation test. And lastly, security on the deployment part. More detailed, in the architecture review we do workshops with architects and analysts. We look at the application process and the flow,

what kind of data is the application we use it. We use it because we don't have time for real-time modeling like the OWASP methodology we use a user-risk application in order to do a highly relevant model and extract all the SPS controls and set them as security requirements and of course we check for the connection between the modules, the movement party systems, the authentication, the user scheme, everything that can be done on Abenza.i.e. Also what a lot of people forget to do is monitor their third-party libraries. And those that monitor their third-party libraries usually forget to monitor the dependencies of the third-party libraries. So we use Naven and our AR system that the developer team is using for building in order to extract all the

dependencies and monitor them. NPM is a bit. It's very difficult to do, but we have to work with that. We use the EOPask dependency check tool which is not so mature but it gets most of the work done and then in demand verification we are checking the dependencies on an event databases

on the deployment part and this is done on the security screens but also anytime that a change is needed we set up the WAF configuration on the application XML firewalls, we either use hardened JPMs or try to like Baratech for example or try to look out of the JPMs that the team is using. Doge image is hardening and self-check scripts. The deployment tools which usually have a very common configuration like self-muppet and they expose a lot of things. and then of course we set up vulnerability scans on the system and on the application. So we have this screen size list, what security needs and now we have in parallel all this stuff as well. So this way we can try to

do a more and less and more efficient security for starting an application.

That's all for me. Any questions?