GitLab GitLab Webinars, 7 Feb 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab - DevSecOps and Compliance EMEA Webinar

Description

GitLab enables developers and security to work together in a single tool, allowing for proactive security or “shifting left”. This session will cover what GitLab offers, how scan results integrate seamlessly with merge requests, and how to use the Security Dashboard to manage vulnerabilities.

A

Yeah welcome everyone.

A

We have quite a good attendance today. That's very nice.

A

Few people still join.

A

Okay, we all starts now because we have a lot of slides to cover so I'd like to take as much time as I can um welcome again to this webinar on devsecops in gitlab. My name is Sandra Brina I live in the Netherlands I'm custom. Success manager for our strategic Enterprise accounts, Within gitlab in the the German speaking region before we start a few housekeeping options. uh First of all, if you have any questions, please use the Q a button on the bottom of the screen.

A

There's a q a option there and there you can add answers, questions and we answer it either live or through the chat chat.

A

The webinar is being recorded as you've heard, so the recording will be sent to your inbox in the next couple of days and in the end, we'll have a poll to ask your opinion about this. Webinar awesome thanks everyone and um let's get started with this webinar.

A

First of all, what are we going to cover today? If we look at devsecops devsecops is about um adding security to your devops teams, so um in fact making sure that security is as close to your development and operations teams as possible and with end-to-end application security. You need a few things to automate, for example, application security testing and Remediation or policy compliance and audibility is something that you want to automate.

A

But also production, application protection, so protection application and production and secure your platform where all your secrets can live. Etc in this webinar we're going to focus only on how gitlab, secure capabilities can help you find and fix vulnerabilities and how gitlab's manage capability help you meet your compliance needs I, see a question coming in what is accept-ups mean death. Psychops devops is um abbreviation of development and operations where we put development teams and operations teams together more closely together and they are together responsible for deploying the software into production.

A

So it's not purely an operations, responsibility anymore, but also a development responsibility and with the SEC in the middle. We add security to this devsecopes to these devops teams, um and this is what you see currently in the Paradigm of Shifting left security. What you want to achieve and I'll explain that more in the presentation is, you want to add security to your devops team or at least more closely to your development organization, rather than having separate infosec teams doing all of the develop. The security assessments.

A

Okay, that's a bit of understanding, so um this is not about devops. This is more about our security capabilities, Within gitlab, and why is that so important?

A

um If you look at how it how much it will cost you if you want to solve vulnerabilities later on in the process, and you see that the cost will rise exponentially.

A

So if you have a production environment- and you want to fix your vulnerability there, it can cost you as much as 30 times more as you would do it early on during requirements or coding phase.

A

So the earlier you find vulnerabilities and the earlier you can resolve them, the cheaper. It will be.

A

Then um what you see in many organizations, that is, that they have application Security in place, of course, but it's mostly done by infosec teams with um applications, application security tools that are fit for those situations.

A

um Traditional application security teams were built 10 or more years ago, and before we even thought about what devops was or that we do daily deployments, the industry needs to get beyond the simple shift left of giving development a light. Sust static application, security test in the LED IDE, which is was common in the in the past. You have like this call Quality test or static analysis test in your IDE.

A

That gave you local local results, but we want to lead a new era where security is baked into our software development life cycle with a single application that is purpose built for the modern software Factory. Let me see devops really taking a a lift, and we also see that having one Platform One tool to build everything and to be in full control helps you stay in context.

A

If organizations want to shift left security, they need to rethink current tools that Target both deaf and SEC teams. So devops is about breaking silos. As I said, you want to add security capabilities inside of your Dev organizations and have them work together with the growing importance of for security organizations for security organizations need to scale security because organizations scale too they grow constantly. Software is more and more important, and this can only be done by empowering Developers development teams tend to scale much faster than security teams.

A

It is our vision that developers play a major role in finding and solving security vulnerabilities at an early stage. That's what devsecop's all about this means that application security tools is running early and often automatically triggered by a build pipeline.

A

Devops is about improving your deployment frequency, so if you have multiple deployments a day or a week, you also need the security tooling to run as often as that Legacy application. Security, tooling, is often usage based priced, so your license is based on how often you ruin the tool and in that way organizations are penalized for scanning. More and more often, infosec teams are also still often the owners of application security tools, which brings the results of security. Vulnerabilities outside of the scope of Developers devsecops, doesn't scale without developer enablement, Automation and exception based security.

A

Infosec teams need to rethink their approach on security scans, adapted to the modern way of software development.

A

Let's look at how a current traditional application security silo, Works many in often times so we see a developer committing to a repository, then the merge request is merged and the deployment is running against a test environment, um traditional application, security tools, these sust or dust, the dynamic application security tests run against an existing test environment.

A

A dynamic application test has to have a running environment to test against, whereas a static analysis test can run on the code base itself, but you often still see that these dust test reports are sent to security teams to infosec teams and they dismiss the vulnerability or create an issue which is then sent to the developer.

A

And often you see that developers have gone on with new tasks and completely forgotten and they're completely forgotten, but they have to go back into context on what was this vulnerability about again?.

A

um So if you can improve that- and let's say hey if you want your developer to stay on top of your vulnerabilities, if you can scan your codes or Security checks every day and time uh seamlessly for Developers developers have it built in into their build pipeline, using fewer tools and with all of these teams on the same page with the same requirements, then you also have happy compliance Auditors right.

A

A gitlab enables this by offering one application that spans the entire software developer, lifecycle it's, and that includes application security tests. We are uniquely positioned to truly improve the workflow of both deaf and application security.

A

This is our devops lifecycle, as we see it and with gitlab all of these tests. So the sust is the container scanning dependency, scanning sequence, sequence, detection, scanning and more are automatically run with every merge request. You no longer need to choose between risk cost and Agility, because it's one tool for the entire software development lifecycle. You can use it on every cloud commit all of these tests are running with every code commit automatically I'll show you that later the gitlab application creates a complete review.

A

App live with every merch request, so Dynamic testing can be run on this working code as well all very early in the software development life cycle. There's no need to buy separate single solution tools, and if you already have such signal solution tools, then you can use cost by using them sparingly with you can get with using gitlab for every code commit.

A

Each of these guns, of course, have a lot of abilities or may have a lot of vulnerabilities, especially the first time you you run it. What would you do if you find more than 10 000 vulnerabilities at the end of yourself at 11 of software delivery life cycle? Does this create new liabilities for you?

A

If you can't fix them right away? Are they now an even greater liability, because you know they exist with gitlab? You can automate the software Factory to apply the policy that you require. Now you can focus on the exceptions not on managing spreadsheets or long lists of vulnerabilities.

A

A

A lot of questions coming in, which is great.

A

um In one of my previous slides, it said he asked that is. Let me go back a bit. What's the difference between EOS and um dust, it was on this slide. It said, and he asked is interactive application security testing.

A

That's in fact a way of instrumenting, an application where the app could be automatically tested for security vulnerabilities, while QA tests are done. In the meantime, the intent is to enable developers with a working test. Application is still required and you need to instrument the application, of course, with dust you don't need to instrument application just once from the outside, looking at an application as a sort of a black box, and they are running uh different Dynamic tests on things like apis or web fondants. There's also API phasing tests and other similar.

B

A

Tests that will also run against a heavier, for example,.

A

Okay, let me go ahead, and so um how does gitlab shift left on security?

A

um Let's look at what we see as a typical workflow uh for applying security. So with gitlab, you can run all of your security scans before the code is even merged, as I mentioned earlier. What does it mean before the code is merged? So if you look at a typical workflow for developer, then developer will commit something to the gitlabs repository that commits will trigger a CI Pipeline and throughout the CI pipeline. Security scans are run and also a review. App is deployed against this review app.

A

The dust scanning can run and on the CI within the CI pipeline. All other scans, like SQL detection, assist scanning, are running so within that merge request and within that commits, the developer immediately has a security test report and based on the findings in that security test report, you can either fix vulnerability, dismiss it or create an issue for it.

A

That way, when an issue is merged, vulnerabilities might not even get into the team of the security environment, the the infosec team, so the infosec team might not even see the vulnerabilities that the developer already resolved in the merge request and when a.

A

Application is deployed, and then the security team can see after the emergency request. Merch regress is merged on a supportive dashboard which vulnerabilities are left and they can still dismiss or create issues on those remaining vulnerabilities.

A

So the key to gitlab's approach is scanning. The code at the point of code commit so early as possible before the code changes even leave the developer's hands, the developer can iterate and add more commits to fixed vulnerabilities or, with certain compliance workflows, they can ask for approval by an infosec team to approve emerging Mass before moving on.

A

In the pipeline, you can run many different tests, we've already previously seen them uh so static application. Security testing, which detects vulnerabilities within the source code similar, is infrastructure, as code scanning, which also checks for vulnerabilities in the infrastructure code, terraform or ansible Scripts um other more static scans are secret detection, which checks for passwords credentials. Also private Keys Etc in your code and dependency scanning is also quite static, which tries to build a software build of materials and all your dependencies that you are using and text that against the cve database license.

A

Compliance is more like a compliance framework where you can allow certain licenses or not. You can also block certain licenses being used and then, if a dependency, for example, is using that license, you get a warning out of that um container scanning is winning also but aesthetically against container images and not winning containers um that other one might be something that's coming soon. But for now we are running against images, but then you have several more Dynamic scans, so cover which guided fast testing detects and expected behaviors and program methods level.

A

um So you, you have like a sort of instrumented environment and bust and type API phishing uh tools that run against a running test environment, a running review app and they checked for certain vulnerabilities inside of that application.

A

uh How does how does it look in a pipeline? So if you, if you use, for example, Auto devops you'd have a build pipeline that can look like this in the build stage you wouldn't build and then in the test stage, you'll run all the tests. This can be uh or is typically on merge, request level.

A

So the container scanning dependency scanning on in the test stage, then a review app is deployed and the dust can and they and potentially the web API first in test run and the Dust uh stage this pipeline can, if you, if you merge the merge request on the uh the master position or the default Branch, this pipeline can also still run all these test scanners, but then we'll deploy typically to a staging of production. After that.

A

Within the merch address developers see as I mentioned before, they see immediately a report of the funds vulnerability. So here you see what developer, what the developer can see in gitlab. The merge best will show you if the merge request needs to be approved. In this case, you see approvals from different teams like project management or politicians, which you also can also have automated approvals, where you can say hey.

A

If, if too many vulnerabilities are found on a certain type, then it automatically requires an additional approval from an infosec team, for example, or you can say that the source scanner is automatically approving if no specific new vulnerabilities are being found, something like that is also configurable.

A

If we drop down here, you see this drop downs and if you drop these down- and you can see the details of these vulnerabilities, you can see it immediately what formulabilities are being found- and you can also click on on each of these vulnerabilities- to see what's happening.

A

um So this as a developer, as I said, you can immediately see within the context of the merge request. Also, if pipelines are failing is also visible in this merge request, so you can see immediately, which vulnerabilities there are and how you could possibly fix them.

A

He can look into the details of a vulnerability in ucx immediately where it is located where it is found what the inscription is and from there you can immediately take action. One action is, of course, to add a new commit to the same um Branch I say: merge, request to fix this, but you can also dismiss it at a comments why you want to dismiss this or you can create an issue and in the issue you can discuss, for example, is infosec how to best resolve this issue.

A

A

Material, so in this training module, you will automatically learn about this vulnerability and how to resolve it in your code, if you hints and gives you best ways to to prevent or avoid these situations and for dependency scanning and container scanning, you often have any cve database, the version in which the vulnerability is fixed and from that the dependency scanner and the container scanning take the new version, and it can automatically resolve this vulnerability through a merge request where they will upgrade the version number of that.

B

A

To a non-vulnerable version that way you can simply click and it will automatically create a match request for the suggestion on how to fix this.

A

Cool, let me have a quick check on the blessings again. So what is a video app now interview? App is a deployment of your application, for example, on a kubernetes investor, where your application is deployed in that community on this cluster on a temporary basis, so it only deployed during the merge request, and then you have an immediate best environments available in your merch request. That is being cleaned up are pretty much request, is merged.

A

Another question is: uh let's get that equipped with the tooling necessary to guarantee, as as LSA levels, two and three philosopher left League life cycle governance, Tunes use, binary, binary authorization as a deployment and um I'm not sure what slsa levels are, and so this is I mean. This is a bit of a difficult question for me, which I can't answer at the moment so I'm going to take this one offline I might come back with increasing a follow-up or something um is the input checks.

A

Basically, infosec tests are added built tests them in the pipeline.

A

I'm, not sure how to see this question um if I interpret interpreted correctly, then I would say to the infosec teams are basically smaller teams in a larger organization that have to manage vulnerabilities for many teams and they typically assess applications, for example, before they go to production, and at the moment that often happens they are the participant has ended, and what you want to avoid is that deployments are delayed to new project teams are fully flooded with so many requests.

A

So what you want to do is you want to automate as much as possible, and you want to take I, see many vulnerabilities as early as possible, rather than leaving that until the end, if you can already resolve a lot of vulnerabilities before it even release, you know, Merchant passed and infosec teams have a very less work to do and they can focus only more important stuff.

A

Open it answers your question: let's continue because we have still some ground to cover. um No, we now have seen what developers can do to resolve vulnerabilities, but also, let's look at what happens when emergency request is merge and what you can do, then what you can see them.

A

So, first of all, there is this security dashboard in the main menu of gitlab, where you can configure your own security dashboard, so you can select which projects you want to add in this dashboard and- and you can see from this group of projects, uh how the vulnerabilities look out over time, and you can even see that project security status right projects are rated based on the amount of vulnerabilities and you get a status, and you see what projects are in that status, and you can also zoom in on that.

A

This dashboard is meant for security, directors or ctlers, or something like that. So you have like an aggregated field, but you can also see then how it improves all the time.

A

If you are in Project teams- and you want to miss the creative vulnerability report for projects, you can use this vulnerability report, which is also in that security section, and you can see um by a type of vulnerability what is found in that group of politics in that specific group of projects by which tool it is found what the description is. So you have your tools like the developer, has on the on the emergency request level: how to manage the enters. These vulnerabilities.

A

Project level, then, you also have specific tools on vulnerability, dashboards and vulnerability management. Again, you can see over time how things improve and also you have this same vulnerability, Dash and what they intend still to control, vulnerabilities vulnerability and three options. Also, here you can result with dismiss it like a set of status on this one really teleport and also select, for example, all vulnerabilities then select a few and immediately dismiss them in in bulk, and also we go into the details of it and then resolve it. There.

A

Cool: that's um management for the security teams or, for example, product owners that will have to do the vulnerability at project level, but you also can automate things and that's the compliance information um like information helps in being compliant under certain standards. It also helps in automating the infosec workflows in your project, but when I see it in my microphone and let me switch to another microphone, then that sometimes happens. I must say.

A

Thanks for telling me that, so this must be better in my um audio quality.

A

Sorry, for that.

A

Cool now, what I just mentioned is that um you have these vulnerability reports and vulnerability, dashboards on Project level and, on instance, level lenses level. You can create your own dashboards based on the projects you want to see. You can also dive into project or group level where you see the group all the project within that group or the vulnerabilities within a project.

A

These tools are typically aimed at infosec teams, csos compliance, people or protocols, for example, that want to have overviews of all the vulnerabilities found um on the compliance part uh yeah you want to be compliant and but also you want to possibly automate certain workflows.

A

So, let's go into this um yeah.

A

If you want, if you have a large instance and or if you are in an area where compliance is very important and we get lab, can help you there too, um we have security and compliance already built in um a single permission model within the entire application.

A

They use, authentication and also authorization is enforceable and consistent. So there's no need to manage multiple of schemas across multiple applications. We can, of course, also connect to your local ldap or whatever, also seeing as an honest possible there's a lot of user management options in gitlab.

A

A

The idea here is that you want to verify compliance in less time, and you want to know what's happening within your development organization.

A

One second, the gitlab enables compliance without friction, so we we have security products um built in into our system. We get them as a secure application and um we help many, our customers securely and managing their software development life cycles. uh So gitlab itself is, of course, compliant with many things, but we we also can help. You become compliance to, for example, HIPAA, gdpr, sock, Etc,.

A

How does it look like a little bit in a compliance framework? You can say: okay, what is your policy? How does your policy look like? Which rules do we have to comply to um which jobs have to run on in which situations Etc? So that's all in your policy management, then you add that to certain workflows and these workflows, you can you apply them to projects, and these projects uh are then bound to those workflows and they will automatically be bound to your Pipelines and yeah. Once you have your pipeline automatically run certain jobs.

A

Your audit management will find activities in the log files Etc to prove adherence to compliance rules.

A

uh How does this policy management look like? We, for example, have merch request approvals in there, so you can enforce merging Quest approvals based on sust kind of results where the Sask scanner will automatically approve when there's nothing found based on the policy or you can have Scan results policies where you say: okay, this is the result of your security scanner and if so, many critical vulnerabilities are found on more than zero, for example, then inform in infosec, and you require an infosec approval. uh Things like that um credentials.

A

Inventory keep track of all the credentials that can be used to access gitlab self-managed instance. So um we we have ways of using, for example, hashico fault where you can store all your credentials in a centralized way. So that's not in in your in in gitlab or that it's not in the code even even worse. We can also make policies of that. We can have Push holes where people can only push against with certain walls in place, different possibilities that we have to help you be compliance.

A

A

Once the policies and rules are defined based on certain compliance Frameworks, you need a way to enforce these policies, a compliance, controls and automation of compliance, workflow focus on enforcing policies and separation, separation of Duties, while reducing overall risk. So you can see that gitlab offers the ability to create templates to enforce rules and policies.

A

These project templates can be applied to oops and and all projects in the group have to use that project template to expand on those kitlab offers also compliance framework project templates, where you can create projects with issues that map to specific order protocols. So you can help maintain an audit, an audit Trail as manage compliance. Programs GitHub also offers compliance framework project labels, where you can enable common and compliance settings to be applied to project with a specific framework label.

A

But how does it look a little bit? First of all, you define your compliance Frameworks and your required CI jobs based on specific compliance. Yeah is a compliance, certificate might say, and Spock 2 is another certificate, but it's at least um a label that you get, and then you apply these. If you assign projects with a certain label, for example, ISO label and then automatically the project, a is.

B

A

If it runs a pipeline automatically um sust and dust scans are added to the test stage based on the compliance framework label.

A

You can see that he is configure that ESO requires sustained dust jobs. Then you apply this label and you'll see the trust, invest scans, being added.

A

As an auditor, you want to see and manage what happens. We do a lot, a lot of audit events, for example, project and group actions, sharing options, permissions approvals, logins Etc, and we can even stream audit logging events to external systems, and we also lock everything within our guest lab instance, where you can see it with that.

A

Gitlab answers questions with gitlabs all the defense that aims to satisfy Organization no audit logging requirements with UI or via API um gitlab also gives you a compliance dashboard that aims to provide compliance, insights and consider Consolidated view with all relevant compliance signals such as the segregation of Duty framework compliance, license compliance Pipeline and merge request resource So. Currently, the dashboard focuses on most recently merged, merge, request activity.

A

This is an example of this compliance dashboard, where you see the merge requests that have been created and the results with it, so PCS, okay, this is all green, but here you see that it has to be approved by people Etc. You see in one overview on compliance level.

B

A

These projects being compliant.

A

I also saw a question on tutorials and workshops, so we do have trainings. These trainings are not free, so you can order them. Security, trainings or develop fundamental trainings are interesting here. um This is all Professional Services Department that can help you order these trainings. There is also on our docs page tutorials on security and devsecops right, and you can find them on docs.kitlab.com.

A

And we do have workshops sometimes um I'm, not sure if it's also on devsecops and and if they are free.

A

If you are a customer, and you have a customer success, manager assigned I would recommend asking your customer success manager for this.

B

A

All the slides so allow me to launch the polls for now and then I can move on and answer more of your questions. But first I will launch the poll.

A

Thanks for answering this, it helps us in um making our webinars more useful and more helpful for you guys.

A

We run these webinars on a monthly basis. Every month we have different topics that we run I, think it's even three or four webinars each month that can range from Advanced cic pipelines to topics like devsecops. So please check our handbook on these webinars.

A

That Cyclops is definitely a topic that will be repeated more often, and definitely also the questions that you will ask. We might improve our slide stack for the next time.

A

Cool I see a huge percentage already answer this question so things for that to be about half now yeah I'm, going to enter the poll in 10 seconds. Nine, eight, seven, six, five, four three two one! Well thanks all for answering that um now, let's focus on all the questions that I asked I'm going through them from top to bottom.

A

If there are any more questions, simply uh at them in the Q, a section and I will try to to answer them. We have plenty of time, so it should be enough time to answer all your questions.

A

um The the slsa I saw someone telling me what that was later on. As a let's say: GitHub SLS, implementation and I have to really um I click. The link now which I maybe shouldn't do.

A

um I have to really look into that. What slsa means and how that's implemented.

A

um I will try to add this to the follow-up email that that is sent later on.

A

And bring it away now is does if dust is against a winning application shouldn't there be a deployed job in your pipeline.

A

um The the um the dust scanning is running against the review up and the review app is deployed in your pipeline. It's one of the slides, maybe I can get to that. One.

A

Yeah same because yeah sorry, um this is the review app, which is deployed here and in this slide you see here here is the the job that will deploy the review app, and this is a special deployed. So it is, there's certainly a deploy job which which deploys a job to a review environment. So the environment is created and that's called review app and mostly with a sort of random number based on the pipeline or the commit or something which is then deployed to um to kubernetes most likely or something else. It can be anything.

A

So that's done in a in a review stage.

A

And and if you run, if you merge the merge request without devops enabled then in the um the pipeline is triggered after the merge request is merged, it will automatically also destroy the review, app and clean everything up.

A

Please provide the documentation link to learn about devsecups yeah. Okay, let me do that in the last bit of this person.

B

A

Is very nice, so I have a bit of time to to look to look that one up. I can do that. Definitely how to leverage and integrate sust tools of fortify to ask them. Inspector yeah I see a lot of tools for the five web inspects black dock sonotype lifecycle, um I'm. You have to look into documentation of those Integrations with these third-party tools.

A

I know that you can integrate third-party Tools in gitlab Ultimate, where you should deliver a specific file in the job, so you have a job that will click the test, for example in fortify or in web inspect.

A

These tools will most likely return a result of that scan of that test, and if you can modify that result in a way that it's um it's given a file adjacent to format of file that the soft scanning can read, then that file is being picked up by the by the job result, and it's it's um well, you say it uh it's scans and the results of that Json file are then added to the vulnerability report.

A

But that way you can indeed include third-party tools into your job pipeline. We are definitely working on it to to make these Integrations even more easy.

A

uh That's work in progress at the moment, I'm, not sure when that's coming, but that's at least the focus of uh last fiscal year, and it will continue to be our focus in the next on any sample project demo. Projects um I need to follow up on that afterwards. I have no links available at the moment, but I can definitely try and find some. We do have tutorials, um but there might also be a demo project or a project template in the inkit lab available.

A

But are there any plans to support Vex and csaf in Cape lab I have no clue what Vex and c-a-c-s-a-f-r.

A

uh Vulnerability review has typically a longer life cycle than a single merge request. That is definitely true. So, within the merge request idea is to to capture or to catch their most of the vulnerabilities on many vulnerabilities.

A

They can be resolved by, for example, using this.

A

This dissolved by merge request option when you immediately increase the version of the dependency or when you can apply a simple, um simple code, snippet to fix a soft vulnerabilities vulnerability, and in that way you are able to take all the easy stuff, all the low hanging foot away from the infosec teams, um and if you can get all the the easy to shock to solve vulnerabilities out of the list, then what remains in the vulnerability report afterwards after the merge request has merged, is the list of vulnerabilities that are difficult or more difficult to resolve, where you need indeed infosec, to help you out in finding a good solution, um so yeah I agree.

A

There are many vulnerabilities that are typically have a longer life cycle than a single merch request, and there that's where you use the vulnerability dashboard. That's where I use the vulnerability reports on Project level to fix that and I would definitely recommend, create the tickets of these vulnerabilities to guide the the the the preview life cycle and this out of the box. Kit level creates a gitlab issue, of course, but you can also create G ratio.

A

If you have keyword issue integration uh of a enabled in gitlab, then you can use the vulnerability to create an issue in here automatically.

A

So how to use third-party tools- I just mentioned that so there are some Integrations and, as I said, if you can make a report, that's coming out of these tests as GitHub extracts them. Then they will automatically be picked up and we are working on third-party Integrations.

A

But can we offer a view of how many pipelines are implementing the security feature.

A

um Yeah pipelines is difficult so projects. Maybe there is a devops reports, on instance level or on group level, where you can indeed see if.

A

Groups or projects are using, therefore, devsecops tools- security scanners- it's a bit rough, so you only see if at least one or more- but you don't see how many projects are using security features, and it's not very fine grade in which security features are being used.

A

So yeah, you see a little bit of it, uh but not very detailed. Unfortunately, and that's something maybe we could uh answer to could add in the future if you're using compliance pipelines, though, where you say hey these in this compliance pipeline, these jobs are mandatory for every project and you apply these compliance pipelines to your top level groups. Then you are 100 sure that all projects in that group automatically use these jobs.

A

Are the sust and dust jobs added by the compliance framework, language, agnostic, the sustained jobs, trust and dust jobs are already language agnostic by default, so they try to determine what type of language you are using and then, when it accordingly, that's based in that's built in into templates that we offer in gitlab. So if you go even if you have a self-managed instance, if you go into gitlab, then there are certain templates uh that you can include in your pipeline.

A

That's all documented, so I'll, try to add documentation, links to your to the follow-up email um where you can simply use a template, for example, job slash scanning or something, and that is language agnostic by itself and what languages are supported is documented in our documentation page.

A

So normally, there's no additional configuration required to make it language and diagnostic.

A

Yeah but body I've already answered that's most of this is only available in the ultimates right. So yes, that's true. Definitely the compliance uh part and the vulnerability reports are ultimate features um on even on the free instance. We are now do support many of the security scans, so you can run many of the security scans even in a free version, a Community Edition and what happens then is for example, if you run a SQL detector, then the job will run.

A

It will output a Json file with the report of your vulnerabilities and you can you have to them manually check the vulnerability of the Json file if there's anything happening, so you can definitely run the scanners already and create outputs, but you have to then manually look into the output. All you have to provide something yourself that will take the output and read it. Read it automated in an automated way.

A

Yeah, how to use fortify SAS in gitlab um I I'm, not sure how to do that. It does make sense to to search in our docs if there is a fortify integration with gitlab.

A

um Otherwise, if you are able to trigger fortify from get from a gitlab, build job through an API call or something and retrieve the results from it, and if you're able then to modify these results into a format that gitlab can read, then that's how an integration should work but I'm not sure. If there's already something.

A

Then the next question I identified I, get that Vision page for supply chain security, including slsa, here yeah, okay, I I'm, going to look into that after the webinar find out what this slsa and everything is and.

A

Then um I will follow your email.

A

Sorry about that, it's the charm of working from home, I. Think, okay! um Is it correct that you don't have to use gitlab's own review app to enable the dust job? The dust job is configurable to point to any at any URL yeah, so indeed the dusty up is configurable to point at any URL. That's definitely true. Therefore, you don't need to use gitlabs or review app. You can write so you sort of your own deploy app that will deploy a review or a test environment where your dust job is then running against.

A

um Yeah how to use task solution weapon specs like fortify I I'm, not sure how that how that integrates uh if it integrates as I say, it also depends on uh the third party tool if it's allowing us to integrate.

A

um Let me follow up on that too.

A

How to use open source software scanning um um is that supposed to be license scanning I'm, not sure always has scanning.

A

It sounds like a license compliance scanning, so what license compliance scanning does? Is it will scan all your libraries and all your source code in your repository and will check what license is being used and it will give you an overview of all your licenses and then, after that, you can set a policy on that license. So you can say this license is allowed. It's not license. It's not allowed Etc.

A

If you run your license, can again the next time, and if you, if you have a dependency that is using one of the blocked licenses, it will trigger the new vulnerability uh and that's also something that will win. As you can see here, early on in the test stage,.

A

Hopefully, I have answered that one too how to use dashboard in gitlab for deploying the app's build artifacts to various environments.

A

um I I can't see how this relates to security so and I'm not sure how to answer this question either.

A

uh For me, this doesn't really sounds like a security uh thing, so we do have environments. We can you can Define them your own sort of if your environment, but also production, staging environments. We have uh our environment space in our release, page where you can see what is deployed where, if you're, using a deployed job with an environment set um but I want to leave it at that, yeah effects is then vulnerability. Exchange I will check that later on.

A

Do we need to run the cicd pipeline for security scans for uh a a uh I'm, not sure what that's what's saying there if we commit and merge to any branch or default Branch? What do you recommend?

A

um I definitely recommend to run all the security scans or as many as you can, uh on the merge request, prevention and also on the on the main branch on the default branch. The default Branch runs after you've, merged and uh yeah. Then you run it again on what may have been changed on that default range, but I would run them as soon as possible in devops and also in in cicd. The goal is to have early feedback, but yeah. This adds also a lot of extra additional feedback on your security status.

A

Many of these these things, especially the dependency and sust scanning, if you, if you know immediately hey this dependency, is, is wrong or hey I'm doing this code, but it's against our code quality standards. Then you can immediately fix it before you are starting to use it everywhere and then it's a lot more time to to fix things. So I would definitely recommend an auto devops template also once uh all these secure scanners in the test stage, for both the merge request, as well as the default branch.

B

A

Very close to time.

A

I think I've and there's one question left that I can have a look at. If is there any live example, or it helpful posture to understand all this Pipeline with deaf second features yeah. That question was also earlier. If there's anything on tutorials or or things like that, I will look it up and make sure that's that that that's in the follow-up, email um yeah a lot of questions. Thank you for that. I've learned things too, which I'm grateful for and um I said.

A

I will add a few of these things to the follow-up email and then all is left to. Thank you all for joining and for your time and um hope to see you sometime next in a new webinar that we run.

A

Thank you and have a good day.