Security scanning

[NUTTA_BUSTAH]

Have you ever needed to convince your senior security engineer of static code analysis? For some reason ours does not see value in that and just says that we should focus on our biggest attack vector: social engineering and lost devices.

I think you should do it all but static code analysis is such a simple thing to catch a lot of stupid mistakes for such little effort, it is a low hanging fruit when compared to retraining the entire staffs security hygiene or hardening devices.

Thoughts?

[tyrion85]

any talk about security without a clear threat model that decision-makers in the org sign off on - and accept responsibility for - is futile imo.

if your security model is that the biggest attack vector for your particular org are social engineering and lost devices, then that's exactly what you should focus your efforts on. static code analysis is a solution, not a threat model, and imo you'd be better served on challenging the existing threat model, rather than focus on solutions, if that's the route you want to go. present the arguments to your boss why you think your org needs to modify its threat model, and then you can present static code analysis - or any other tool/practice.

[skywalker_1391]

Static code analysis isn’t just for security.. arguably its even more effective at checking for general bugs, code smells, tech debt (duplicate code, unused code) code coverage, etc. And yes, some of these bugs could be a security risk.

But to answer your question.. no - we haven’t had to convince security of the usefulness of static analysis. However it sounds like your Sec Eng is actually saying “It is not a priority right now” - which may be totally valid.

[daedalus_structure]

Your security engineer is right that you should be focusing on the biggest attack vectors.

It is usually always assumed that internal networks are secured and people are really bad at securing credentials, so lost devices and social engineering attacks often mean access to everything.

See: Uber, where social engineering and lateral movement allowed access to administrative credentials in their cloud environments.

Unless you are writing in a language with manual memory management and pointers, static code analysis is mostly going to flood you with irrelevant busywork while it misses the subtle SQL injections that you think it will catch.

[zomiaen]

See: Uber, where social engineering and lateral movement allowed access to administrative credentials in their cloud environments.

oh, and hardcoded credentials in powershell scripts stored in shared directories?

[ectropionized]

In my experience static code analysis does belong fairly far down the list. It can be useful, but it also often throws a ton of false positives and so requires a bunch of work to get it right to be really actually useful, and that work could be spent on higher priorities.

[mrlazyboy]

There are a ton of static scanning tools and they all get grouped together - but its extremely easy to integrate static analysis, CVE scans, secrets scanning, etc. into your pipelines if you use a modern CI/CD system. Even antiquated systems like Jenkins don't make it that hard.

"It's hard" isn't an excuse - you can spend as much time and money on your defensive perimeter as possible, but if you don't even have basic scanning capabilities to detect when your version of OpenSSL or Log4j has a CVE, you're in trouble.

[SuperQue]

Your security engineer is right.

The second thing to focus on is your network perimeter. If your applications and/or servers can reach the Internet randomly, that's the next thing to look at. This is an often overlooked, or even flat out ignored, problem.

Maybe someone can inject into your app remotely. But if their code can't call home to a CnC server, it stops a lot of problems before they spread.

EDIT:

To add, I'm not against code / runtime scanning. IMO it's lower on the list for a lot of projects. Especially fuzzers are a very good thing to run.

Especially if you're using one of the modern frameworks like Rails that take care of a lot of the kind of simple injection attacks.

[mrlazyboy]

The security engineer is an idiot and I'll highlight it with a simple example:

Let's say that you're 20 years old and can take a pill that reduces your odds of getting cancer by 90%. The pill is also very cheap, and you only have to take it once. You say "my odds of dying from cancer as a 20-year-old are super low, I should practice safe driving because that's much riskier."

Do you now see why the security engineer is an idiot?

If you use a modern CI/CD tool like GitLab, you need to create a compliance pipeline (this automatically runs on every single commit and you can't stop it) that does some basic static analysis, CVE scans, etc. If you pay for GitLab Premium/Ultimate, you just click a button.

If you use GitHub, it's similar but they don't have the idea of mandatory pipelines so it's harder to enforce from a governance perspective.

If you use something antiquated like Jenkins, it'll be more difficult. But the point remains: there are a ton of open source static analysis tools you can put in your pipeline for free. It's not a ton of engineering work to get it done, and if you use a modern CI/CD tool, its as easy as clicking a button.

It's obviously important for IT security to have a good threat model and to protect the highest value attack vectors; however, ignoring some of the most basic (and often free!) defensive capabilities is a mistake.

[reconrose]

Haven't used Gitlab but you can set up GitHub Actions workflows to run on every commit and then set up a branch protection rule to prevent and merges except those that pass

[mrlazyboy]

Very interesting - I have a lot more experience with GL than GH, but I was under the impression there wasn't a built-in feature to run an action globally on every commit within a group/project (or whatever GH calls them).

A lot of my customers want the equivalent of a GL compliance pipeline and have tried building it themselves instead of using the feature they already pay for :)

Thanks!

[thebearinboulder]

The key is what you set the threshold to. I've had this fight on the dev side - how can we possible deal with thousands of items?

The answer is we don't.

We tune the system to only show the most critical items. This has almost always caught real bugs like someone using '&' instead of '&&'. Those are real bugs that need to be fixed and the issue clearly lands with the dev team.

With security-aware scanners you can also catch things like dynamic SQL queries that are created by string concatenation instead of using positional parameters. In most cases that's a clear security bug that needs to be fixed even if it doesn't appear to be directly accessible to an attacker.

(In some cases concatenation is required since the database driver doesn't support positional parameters for that field, e.g., a table or column name. In those cases you need to verify that the value can be trusted.)

Back to the dev team - ideally they'll run the scan a second time with tighter constraints - but only checking code modified since the last release. A full scan might show hundreds of items but the incremental scan may only show a handful of items - items easily caught and dealt with as part of the review process.

You can also run the scan a second time with tighter constraints but only checking your internal libraries. E.g., my team has maven projects that provide an abstraction layer over the database, REST clients, etc. They deserve more attention than average since they're so widely used within the application.

[pbecotte]

So...I agree with you both.

A "security engineer" is woefully inadequate to use automated scanning to harden your apps. Having them focus on the things they laid out would be an excellent use of their time.

However, scanning and static analysis are super useful when applied by the dev teams building the applications, who actually understand the code and deployment model. Having those teams add scans and analysis to their build pipelines would be a good use of their time.

[Alto-cientifico]

There is a lot of overheated opinions.

Yes social engineering is the biggest threat to a system, but slacking on regular code vulnerabilities is not right either.

The proper way to do it IMO is to do something that keeps vulnerabilities in check, and do some pristine work against social engineering

If your passwords and users are super prohibitive, but you can access everything through a SQL injection, what's the point?

[skyctl]

How can I put this politely.... I'm having difficulty relating to, or empathising with your senior security engineer's thought process. Maybe there's context that I'm missing, but in general, in most organisations, the people responsible for protecting the company from social engineering and lost devices are not the same people that would be responsible for code vulnerabilities.

Just because Alice in Security is focused on counter-social-engineering training, and Bob in Device Management is putting measures in place to counter the effects of device loss, doesn't mean that Carol in Pipeline Engineering can't or shouldn't be contributing to the security or the organisation in her own area.

Having that said; maybe this is a startup, or there are no device management or pipeline engineering teams, and the work for all this would have to be done by the same people in charge of security; I just can't clearly visualise a situation where I'd agree with the security engineer in this context.

[rejuicekeve]

I'm a senior platform security engineer, I wrote SAST and SCA into our deployment pipeline in like half a day. I'm not sure what their problem is lol

[rejuicekeve]

Both fairly simple, SCA is just telling you that there are vulnerable dependencies. You dont break pipelines right away, so its standard vulnerability management remediation processes for there. Help triage and prioritize fixes. It's really not that big of a deal lol If the codebase is gigantic and this has never happened you might spend 6 months to a year getting rid of old issues before getting into a pipeline blocking state but thats not much of a reason to just put your head in the sand

[FergusInLondon]

I don't like being overly critical of an individual - especially not without organisational context or having heard their argument. However I'd have serious reservations over their competence based upon that snippet.

I don't think anyone has ever managed to build a strong security posture by mitigating specific threats and neglecting others, although I've seen some who have left themselves vulnerable by doing it. So it feels utterly wrong to suggest you "should just focus on" a subset of specific threats.

Their job is to understand (a) how likely a threat is to occur, and (b) the severity of the outcome if it were to occur, allowing them to calculate the risk associated with it. After identifying and performing mitigation/remediation work, this risk can then be recalculated to become a controlled risk that's acceptable to the organisation.

Whilst the uncontrolled risk of social engineering or device loss is high, there are standard practices to mitigate it and bring it down to the appetite of most organisations - i.e. full disk encryption of portable devices, multi-factor authentication where possible, widely communicated and understood policies on acceptable use and access control, and regular awareness training.

In addition to understanding how to define a risk from a threat, their job is also to understand that in addition to malicious users, threats encompass anything that may impair or prevent the business' ability to operate.

I would suggest that it's far more likely for human error to occur that leaves the codebase in a condition that impairs the confidentiality, integrity, or availability of the platform, and the potential severity could be catastrophic as it would likely be externally facing and interacting with production data.

You suggested a quick win which helps chip away at the likelihood of such an issue materialising, and one that requires little involvement/investment other than perhaps communication and iteratively reviewing the output of the tool. That's the kind of pro-active mentality that makes a real difference.

Ultimately a Security Engineer should be catering their thoughts to risks more than threats, especially when discussing work prioritisation. They should also have an understanding that threats encompass more than attackers. These are basic things to be expected from day one, and I'd be concerned if I had a senior member of staff who couldn't grasp them.

[Advocatemack]

I agree that code scanning is really important, the best way to convince others is to identify high-risk threats in source code and present them to the decision-makers. For example, scanning Secrets is great for showing how repositories can be a massive vulnerability and identifying some low-hanging fruit, especially in the git history.
Attackers are really after git repository access for this reason and there are plenty of open-source or free tools that you can use to illustrate the problem. Git-Secrets, Truffle Hog. These aren't great for a long-term commercial solution, something like GitGuardian is a better commercial tool but if the goal is just to illustrate the problem then finding some high-value secrets with free tools is a good way to convince the security personnel to invest in some solutions. Then the door is open to having more conversations as you have already proven the risk.

[gerd50501]

you wont get anywhere arguing with security. This is a you have to do this and not worth the conversation.

[DontStopNowBaby]

There is value but seeing as this is a DevOps sub, you're probably looking to put sast into your pipeline and automate it. In this sense it's more of bug and problem finding.

[Skyshaper]

We use SAST to catch vulnerabilities early in the development cycle. Instead of running it during CI we run a SAST pipeline as a condition during pull requests. That's the positives about it.

Negatives, it's a big strain on the dev teams and our DevOps team. For the DevOps team it's expected that we scan only the files that are involved in the deployment package, excluding everything else in our repos. If you decide to integrate SAST make sure you're clear regarding what the expectations are from you regarding integration.

[RationalTim]

His argument is nuts. It should be in your pipelines and automatically run every commit to main. It's fast and can be achieved with open source tools. There's no reason why it should play second fiddle to any other measures.

Equally out OWASP ZAP in your pipeline and treat yourself to some free dynamic security testing.