Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Infosec Apocalypse

blog.rickasaurus.com

Post reply on HN
Print view View original

41–50 of 104 posts

Re: The Infosec Apocalypse

#41

Post by pixl97 »

pubkraal wrote: post #9

The static analysis, but also software component analysis tooling are really incredibly helpful though and should really contribute to releasing stable products as well -- it's not just here to satisfy your customers management types, it's there to actually make sure your tool doesn't have 5 RCEs active at any point in time. I for one am happy companies ask about this type stuff, it's basic hygiene to keep control ov…

As someone that works for a SAST vendor I will say it's mixed. By the choices we make in what we support in languages and their dialects we can effect the ecosystem.

And at the same time, I have seen some terrible things that are picked up in code the first time they are scanned, that in theory should have been obvious but were missed for whatever reason.

It gets even worse when you're looking at included libraries.

Also, if you're using these tools, put in requests for new features and languages. This is how we know what customers want and where to focus resources.

Re: The Infosec Apocalypse

#42

Post by beh9540 »

Mountain_Skies wrote: post #7

I recently did an extensive competitive analysis of SAST tools for a client. Anyone who is thinking about buying one of these tools should pay attention to what versions of each language they support. Also try to get old release notes in order to determine when they first supported a particular language version. Many vendors take a good long time to support new versions of languages, even mainstream ones like Java an…

This cannot be stated enough. The company I worked for purchased "the leading gartner SAST testing solution" before they even started a project and had a framework chosen. It turned out the SAST solution didn't support the latest major version of the framework we were using at the time, and didn't support the latest version of the language we were using. Even worse, it never seemed to ever report an issue, and took hours to run at times, eating up build minutes.

I ran bandit on the code base just for fun one day, and we had four hits and it took 5 minutes to run. It took a while, but I finally convinced the powers that be we were better using the tool we could verify works, rather than trusting the SAST vendor that it worked.

Re: The Infosec Apocalypse

#43

Post by schwag09 »

pc86 wrote: post #30
zxcmx wrote: post #10

Earlier quoted context omitted.

Not just languages - Generally if the scanner isn't aware of the specific framework you're using it's unable to find entrypoints or reliably figure out sources / sinks and filters. Many modern frameworks have one or more of: dynamic configuration, compile time annotations, reflection, IoC etc which make it very hard for a "first principles" scanner to make sense of what can actually happen at runtime.

What exactly is a "'first principles' scanner?"

I suspect this means a scanner that can derive all necessary information without any configuration. For example, consider a scanner looking for API endpoint authorization inconsistencies. Does the scanner need you to describe your authorization scheme, or can you simply run the thing and it figures it out?

This can be easy or hard depending on how bespoke your application is. If you're using something like Ruby on Rails, then there's a paved road that a scanner can preconfigure to understand your application. If you're using a homegrown authorization framework, then a scanner will likely have a hard time understanding your application and will need to be configured.

Re: The Infosec Apocalypse

#45

Post by jcims »

ithkuil wrote: post #27
jcims wrote: post #20

Earlier quoted context omitted.

This isn’t worded correctly based on my experience. It should say ‘enterprises no longer trust their developers and SREs alone to take care of security,’. Devs and SRE still have a very important role as SAST and DAST tools only catch a portion of security issues in code and are generally useless for gauging architectural/deployment/runtime issues.

I agree; my response was to the wording present in TFA, which seemed to imply that enterprises expected engineers to handle security and were surprised they didn't and hence now are attempting to force a top-down approach the whole thing will be secure _despite_ engineers doing the same things as before. Tooling helps; no question about that. But you can't assume you're engineering team can be oblivious to security c…

Totally agree. One option is to make static scans a tollgate only at higher application risk levels and/or exposure. For example, low/medium risk internal automation and telemetry tooling? Go nuts. Internet facing, regulated, high/critical risk? Need code scans.

Re: The Infosec Apocalypse

#46

Post by goatinaboat »

nuker wrote: post #17

I see no links between infosec and functional programming.

The link is that FP is usually bottom up and InfoSec is top down and they fail to meet in the middle

Big FP shops will have solved this of course. I doubt StanChart or Jane Street are losing any sleep over it.

Re: The Infosec Apocalypse

#47

Post by newera2016 »

Mountain_Skies wrote: post #7

I recently did an extensive competitive analysis of SAST tools for a client. Anyone who is thinking about buying one of these tools should pay attention to what versions of each language they support. Also try to get old release notes in order to determine when they first supported a particular language version. Many vendors take a good long time to support new versions of languages, even mainstream ones like Java an…

Wow. Great. Would you be able to publish your analysis?

Re: The Infosec Apocalypse

#48

Post by airza »

zxcmx wrote: post #10
Mountain_Skies wrote: post #7

I recently did an extensive competitive analysis of SAST tools for a client. Anyone who is thinking about buying one of these tools should pay attention to what versions of each language they support. Also try to get old release notes in order to determine when they first supported a particular language version. Many vendors take a good long time to support new versions of languages, even mainstream ones like Java an…

Not just languages - Generally if the scanner isn't aware of the specific framework you're using it's unable to find entrypoints or reliably figure out sources / sinks and filters. Many modern frameworks have one or more of: dynamic configuration, compile time annotations, reflection, IoC etc which make it very hard for a "first principles" scanner to make sense of what can actually happen at runtime.

Even Fortify and other tools which have to compile beforehand don't do so well IMO. Someone is going to come up with an actually good SAST and print money...

Re: The Infosec Apocalypse

#49

Post by HFguy »

staticassertion wrote: post #40

I wish we could just all reject SOC2, it's such a grift. Bankers come in to read some docs (that they don't understand), look at screenshots (that they don't understand), take up 100s of thousands in cash and time, and then write a document (that they don't understand) that no one will read or care about (except to fuel their own SOC2). The harm is so significant. Tons of these due diligence terms are driven not by a…

What do bankers have to do with SOC2? Do you mean consultants?

Re: The Infosec Apocalypse

#50

Post by privacy-matters »

HFguy wrote: post #49
staticassertion wrote: post #40

I wish we could just all reject SOC2, it's such a grift. Bankers come in to read some docs (that they don't understand), look at screenshots (that they don't understand), take up 100s of thousands in cash and time, and then write a document (that they don't understand) that no one will read or care about (except to fuel their own SOC2). The harm is so significant. Tons of these due diligence terms are driven not by a…

What do bankers have to do with SOC2? Do you mean consultants?

I think he means a CPA. Certified public accountant. They are the ones who actually write the report.
Post reply on HN