[ttegloma]

> which is kind of interesting...as you would think that the security-minded people work on that tool.

I work in security at a company with similar tools and unfortunately I think this is an incorrect assumption.

Security people aren’t necessarily good developers, and good developers aren’t necessarily good security people. And being “security minded” really isn’t good enough.

At the end of the day, the team building the product has the first and foremost priority of launching the product. This always means cutting corners, or not going as deep as might be necessary for certain issues like this, even if they are “security minded”. You really have to have a checks-and-balances on this by having a dedicated security team that has a priority of first and foremost not allowing security vulnerabilities to make it into launched products.

I’m not sure if GitLab has that or not, I’m just saying that wouldn’t make any assumptions about the security posture of a feature just because it’s a “security feature”. If anything I’d be more wary of them, because in my experience there actually can be an attitude of “my shit doesn’t stink” among people developing security products.

[tyingq]

I guess, though they work on an SAST scanner that identifies problems pretty similar to this one, untrusted input, "confused deputy", etc.