I recently joined a start up company that specializes in software development as a cybersecurity risk management for an internship of 6 months, my first task was to audit the company's gitlab page since all they use for their coding work is gitlab.

Since I have 0 practical experience, I am very lost on how to start, what should I do, how can I actually check the security of the company's gitlab, are there any tools that can help me do that?

Note: There is no Cybersecurity department or team in the company, so far I am the only one working on this and there is no one else to teach me the ins and outs of the job. Not the most optimal internship experience, but I have to get through it I guess, too late for me to change.

So far, I have tried to already define the scope, identify the assets. I want to identify threats and vulnerabilities by using third-party software; I am still lost on which one would be the optimal one, I found Synk and thought it would be good. I have tried to assess the best version of gitlab to use since they are still using a deprecated version of it, 11.2.5 to be precise, which has a lot of vulnerabilities. I am also checking the access controls and the rights given to the users, I want to do a secret scan as well but I am not sure how. Where to go next, what to do.

  • This isn't a risky position. Don't worry. And no, you can't be blamed for an internal assessment.
    – schroeder
    Mar 2 at 16:42
  • A note that questions asking for product recommendations are off-topic, as are requests for resources (books, blogs, videos, etc.).
    – schroeder
    Mar 2 at 16:48
  • I'm curious why you are talking about Snyk and asset identification when your stated scope is the Gitlab instance. Is your scope Gitlab or something else?
    – schroeder
    Mar 2 at 16:54
  • Welcome to the community. I'm afraid you need to do real quick learning by doing - reading up on the relevant parts of cybersecurity and doing some pentests on the software in question here. You might want to fuzz it, check for SSRF, XSS, check exploit db, check OWASP Top10 which applies to any web app etc Mar 2 at 18:12

1 Answer 1


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.


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).


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.

  • You totally missed the context here and what the ask is and you've totally overreacted on the "liabilities"
    – schroeder
    Mar 2 at 16:50
  • I don't agree. There is no Cybersecurity department or team in the company, so far I am the only one working on this, as a cybersecurity risk management for an internship... the scope and context is pretty clear. He's asked to do a Risk Assessment, and questions whats involved... the NIST guidance is abundant, and you can't just assess one piece of software as the Risk is organizational wide. He should take his position seriously, with the full assumption of liability, whether real liability or not. Mar 2 at 16:55
  • You've over-reached to a rediculous extent.
    – schroeder
    Mar 2 at 16:56
  • "you can't just assess one piece of software" -- of course you can ...
    – schroeder
    Mar 2 at 16:57
  • He's being very specifc about it being Risk Management, not software testing and all that. Risk management can't just happen only at the one piece of software, you need to assess the organizational policies and procedured as part of the risk assessment. I think you've misunderstood his objective role, and the liability that comes from that role if he doesn't provide a valuable assessment. A poor assessment not identifying the risks, would put him liable, and that is risky and sounds like he could be used as a scapegoat. Unless you're a lawyer in his country and can confirm he's not liable? Mar 2 at 18:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .