Since you are addressing specificaly the Risk Management for your organization, and you said you're focusing on gitlab as your boundary, I think your organization is trying to approach (in some form) the Risk Management Framework. As with the rest of the information I'm providing this is from the US Government sources;
Assess and Reporting
You can assess just the software as one boundary as part of the risk management, but pen testing and vulnerability scans is just a relatively smaller part of it. Risk Management covers organizational policy and procedure, and ensuring those policies are followed. You need the policies to define organizationally how you secure systems, and NIST has guidance for this in the SP 800-53. Not all the controls in the 800-53 may be relavent to you or the organization, which you can tailor them out and not assess or address them, but you should check with your organization. There is definitely guidance that is similar for other reigons and countries but this is a great start, and they all should map and reference similar controls.
I would talk with my supervisor, and let them know, "here's what I'm going to use to make my assessment. Or do we have some other publications I should follow?"
There is the SP 800-53A which is the guidance for building the risk assessment plan based on the 800-53 controls.
This guidance is holistic, for the entire organization, down to each systems component. That is, there needs organizational policies and procedures to be in place to properly address the controls, where validation that those controls are being performed can be tested on each component.
Again, I would discuss with my supervisor along the way, "This is what I'm finding, do we have these policies? We probably need to have these policies written out before I continue."
For example;
- A control says
the organization protects systems with passwords of [organization defined complexity].
- A company policy document should say
All user entered passwords must be a complexity of 14 characters, 2 specials, and 2 capitals, and 2 numbers.
- You can then test the control by looking at operating system and software configuration files for the complexity requirement settings.
- Your risk assessment would say;
Per cybersecurity policy Section 4.5.2 User account policies;- Repeating the control;
the organization protects systems with password of complexity meeting 14 characters, 2 specials, 2 capitals, and 2 numbers filling in the [blank] with your organization's defined minimum requirements.
- And saying they follow the control and how you verified it;
this was verified by inspecting the configuration file at /var/config/security.cfg for the software, interviewing the system administrator, and verifying with an end user.
That is what your Risk Assessment Report comprises of. Following the 800-53A, it gives you examples of how you can test those controls "looking at policy documents", "asking end users about the control", "looking at system configuration files", etc. This allows you to report confirming or denying that policy is in place, and the control is in effect.
Securing
The US Government also provides what are called Standard Technical Implementation Guides, or STIGs. These are step by step guides for applying controls to known configurable systems, ie. Windows 10, and RedHat. (The redhat stig can be performed on most linux systems.)
Also, Security Requirements Guides, for more general applications like "Web Servers." Both STIGs and SRGs are designed to map to the controls in the 800-53 and "secure" a system to standardized minimum requirements (these may not be your minimum requirements, and STIGs can be overly aggressive, so tailor as you need).
Verifying
Finally, they also provide (I'm surprised all this is public) SCAP, Security Content Automation Protocol, a piece of software that can check the security health of a system based on benchmark files.
SCAP can't be ran against everything, but it can give a general score card about a computer system or software. You can follow the guidance in the 800-53 and apply controls against the software or system you're assessing and securing.
In the end, you can tailor out controls you don't need to meet, based on organizational requirements. For example, you don't need a log in banner, so the findings of that is not applicable, and you can tailor those controls out, and thus changing the score in SCAP results and not reported in the Risk Assessment.
What you don't want to do is to blindly do some pen testing (especially "secretly" and if you weren't hired to do pen testing), and write a report showing "the software is vulnerable to these attacks." Your organization is probably already aware it's vulnerable, they need structured reporting as to why it's vulnerable, and what controls can be put in place to secure it, and what industry standard guidance it meets, that is what risk management is about. Giving a whole risk assessment report needs to be done, this includes organizational policy documents, you can scope it down to the single software as a boundary, but policy is typically written and applied organization wide.
This is not comprehensive to what might be your legal responsibility in your company and/or country, but it's a good start for understanding the process and better than having nothing at all.
