Continuous Delivery Foundation Spinnaker Summit 2022 - Detroit, 4 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Integrating Fortify Security Scans in Spinnaker Pipelines - Asiya Yunusa & AbdulBasit Kabir

Description

For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/

Integrating Fortify Security Scans in Spinnaker Pipelines - Asiya Yunusa & AbdulBasit Kabir, Interswitch Group

Creating custom stages in Spinnaker can be broadly simplified into two steps adding the stage definition in the Orca configuration and specifying what action the stage should perform in its configuration. Custom stages provide a way to extend Spinnaker for use with applications that do not have tested integrations. This session demonstrates how to create a custom stage that sends an API request to Fortify Software Security Center and then parses the response for values that will determine the pipeline behavior.

A

Welcome to the spinaka summit and Welcome to our talk, integrating 45 scans in spinaka I'm, asking us a devops engineer at interswitch group I'm, part of the team that manages srinatha and works on Pipeline design and standardization across the organization.

B

I work with us here so and Asia basically work on the platform engineering team, which, among many other things, we basically standardize and serialize how continuous delivery is done at interswitch, because Industries is a large organization. There are several teams and each team have a set of applications that they manage.

B

Those applications um would definitely need to be deployed to whatever environments we, mostly in schematics, whatever environments that they deploy to, and there are different tools that can be used. So when we started, we had a process where Jenkins was used to build and run some jobs and some CI jobs, and what file was used for security purposes.

B

Basically, 45 is a static code analysis tool and because it's worked in a form of client server, client server approach, whether the client that is used to run the test on the code base and there's a server where the results of that scan is essential for further analysis and basically review.

B

um This, then had to separate like the scanning and the getting of the results and.

B

We couldn't really add that to Spinnaker and Spinnaker, basically is what we used for continuous delivery, um so I think I said you want to explain the whole issue a bit more.

A

Yes, so the issue we had was we had Jenkins running a 45 scan and pushing the results of photos and 45, and then afterwards it pushes a success status to spin up regardless of what the security scan, regardless of the results of the 45 scan. So even if an application, an application security is written, didn't switch. What Baseline was set by the organization Jenkins would send a success status to spinaka and that would allow the pipeline to proceed.

A

So what we had was a pipeline where a fortified Jenkins job is triggered by srinaka and once that job is done, an engineer would need to go to the 45 server and check for the results and, if the, um if the security rating reaches the Baseline opacity Baseline, the engineer would Mark the security check and see this application is secure. So let the pipeline proceed, but if it was below what the Baseline is, then the engineer would mark it as a field stage.

A

So that process was time wasting and we could also not guarantee the results that were brought to provide. The engineer, maybe due to someone, might be able to might make some error or make some mistake when they are evaluating the pipeline and evaluating the security check.

B

Foreign for us, because part of our mandates on the platform engineering teamwork that we wanted to really serialize the whole end-to-end continuous delivery process started on all the good commits to production deployments um again before adopting Spinnaker our we had the different stages done manually and in different places. Basically, all of them were um isolated in order to integrate something like this. What we decided to do was to get to create a custom stage and thankfully Spinnaker has custom stages. So there are two custom stages: the custom workbook and the custom job.

B

um The custom job is basically Spinnaker creating a job or it has based on whatever account here is it, but for the custom Web book. This is basically creating native, like stages that make API calls to an external system and thereby giving you the ability to extend your spinata application.

B

um So you would see the stage on the spinach UI as if it was in um as if it was the native stage where, while it was actually a custom stage and I think we will show that in the next few slides and these stages are basically done by um configuring, Orca and extending it.

B

So with the custom workbook stage we are were able to now create a flow that doesn't, it doesn't have any manual stage and doesn't do any interrupts.

A

Yes, so the flow went or the flow goes this way, so you have spinal car triggering a Jenkins draw and once the Jenkins drop is triggered, Jenkins runs the 45 scan using the 45 clients and after that, Jenkins would push the results of the scan to fortify.

A

So after drinking sends a success status to srinaka the customer book stage comes in and makes an API call to a particular endpoint on 45 and then gets the results of the scan.

A

So after the update, this was how- or this is how the pipeline um looks- the you have your 45 Jenkins job, which is the initial job that is run from on Jenkins. Then you have to get Spotify scan results where spinaka goods and make the API call to fortify and get the results that we need and to validate the results that we get. You have the check, 45 scan status stage, and once all that is done, you are able to deploy your application without any manual intervention.

B

Yeah and um the fact that we could add um a stage that spinner card that makes Spinnaker go out to the 45 server and basically fetch the outputs of the results that was really powerful for us um and so in creating the stage what we did was to man to reconfigure um occur so on the Oka local.aml file, you, um let's say it's, there's a provision to add your books, um so it's called pre-configured Web hook, I think um so what you do there is, you add, a Snippets yeah I must Snippets something similar to this, where the label is the name of the stage, as you will see it on, as you will see it on Spinnaker, um we added a URL, which was basically the API call that is made by the API called that's made by Spinnaker to go and get fetch the results.

B

um We also added some custom stages, some custom headers, sorry, um the custom headers was is where you basically add any header that is specific to the external system like for us. What we had. There was authentication, um you could add other things like payload and um and some statute. Some basically set the status that you want and but for us all, those things were not um we're not relevant, in particular to this particular custom stage.

B

What we needed was to add parameters, so parameters are just like the parameters on your pipelines, right you're, able to give the end user the ability to actually input some values into a field, and if you notice that, if you notice the for the parameters here, we had one parameter and if we check the name, that's exactly what you would see um on line, one where there's the URL and the parameter is actually added into the URL to show to basically fetch a particular endpoint and get the result of a particular application.

B

So, with all these, the custom stage was um gets created. um You deploy your occur, you you save that file, you deploy your occur and the custom suit gets created and you'll see that on our list of stages, there is 45 scan I'm sure for those very familiar with Spinnaker. You will check and what price can isn't a native stage, but here it looks as if it was something that was natively created. So no code was no new code was written, no plugin.

B

We didn't need to write any Spinnaker plug plugin, but we now have the 45 scan stage, which does precisely what you wanted go out to um fortify fetch the results of that particular scan and basically um give us what we give us the results of it add the results into the pipeline.

B

Here's where you would here's, where you see the parameter, basically, that field the 45 application ID as configured on the Orca file. Here, the pipeline admin would actually put the application ID so that it gets added to the endpoints.

B

um Ideally, this pipeline ID, this application ID, gets used when fetching the endpoint, but you could as well use that ID to you could as well take that take the value of that field, that parameter and add it to a payload. If the end points call was the API call was a post request or it's needed AP load.

A

Ideally, you'll be able to add success, statuses on your your upper local file, which would indicate that once the API call is done if the status in a particular Json path is maybe um success or error, then it should either proceed or it should fail, or you should pass that stage in the pipeline.

A

But what we get from 45 is we get integers which, uh which kind of um which identify the number of high priority or physical priority issues in an application, so we're not able to use the inbuilt function of of this influence function of worker.

A

So what we did was to add a spell expression which gets the results of the previous stage and then passes it for a particular value. So for all the values that we wanted and which was specified by the infosec team, was the number of high issues in the application. If that's greater than zero, then the pipeline should feel or the number of critical issues, and if any of this is greater than zero, then it fails the pipeline.

A

So that is an additional stage that helps us to remove any manual check, and once you check the pipeline, you would be able to see the Fortified Jenkins job. You get 45 scan results and the validation stage, which I just explained, and after that you'll be able to deploy your application.

B

Yeah and you you see um adding that adding a stage adding the custom stage, basically helped us achieve the goal.

B

um Have the entrance um delivery process on a Spinnaker pipeline, removing any waste any manual stage, any weight stage, um automating and basically serializing any step in the whole. Continuous will be process that that was used and needed for the whole applications to get deployed all the way to the environments.

B

The Spinnaker pipeline does the whole orchestration of the whole continuous delivery, calling Jenkins and also reaching out to fortify to get the output and making the decision on whether or not um this is a valid pipeline run or not, and that's how we basically solve the issue um inside the Orca file. You can basically create your custom web books and with customer books you can open up a lot of other possibilities, whether it's triggering a a pull request or creating, maybe creating a third party integration with my other application.

B

As long as it has API all those are possible with okay um hope. You found this session useful um I, see I, don't know any other thing to add.

A

Yes, so one last thing to add is that um this is also possible, or there is also a way to integrate fortify with Jenkins, which um is by using the 45 plugin. So by using that you can also get Jenkins to notify spinaka or the security rating either. The security screening is not up to the Baseline, but due to our own environments, we decided to go with this approach.

B

Yeah and that's true, um there are multiple ways of doing the interpretation. You could do it at The, Junction's point or you could do it at the Spinnaker points, but for us um we had to do that spinal points and um basically trying to take advantage of the extensibility feature of spinaka yeah. That's true.

B

um That's on point, um hope you enjoyed the session and um we'll be here for Q A's um and let's see what you come up with with custom workbooks. um Thank you very much and enjoy their service session. Thank.

A