The Infosec Apocalypse

#1

Post by chillax » Thu, Sep 17, 2020, 6:34 AM UTC

The Infosec Apocalypse
blog.rickasaurus.com

Re: The Infosec Apocalypse

#2

Post by RajSinghLA » Thu, Sep 17, 2020, 6:58 AM UTC

Apocalypse is a strong word for a post that ends with no real prediction.

Re: The Infosec Apocalypse

#3

Post by saagarjha » Thu, Sep 17, 2020, 7:03 AM UTC

RajSinghLA wrote: post #2

Apocalypse is a strong word for a post that ends with no real prediction.

It seems to me that the author is concerned that a desire for vulnerability scanning will prevent new languages from entering use because these tools won’t support them.

Re: The Infosec Apocalypse

#4

Post by bawolff » Thu, Sep 17, 2020, 7:05 AM UTC

Meh, if you want your niche tool to break into big enterprise, you have to deal with compliance hoops. That's just the cost of doing business with big enterprise, certainly not a new thing.

If anything, in the long term that's probably a benefit to fancy functional programming languages with complex type systems - they provide much more info for static analysis tools to work with (static analysis is pretty highly related to type theory)

Re: The Infosec Apocalypse

#5

Post by bawolff » Thu, Sep 17, 2020, 7:21 AM UTC

saagarjha wrote: post #3

RajSinghLA wrote: post #2

Apocalypse is a strong word for a post that ends with no real prediction.

It seems to me that the author is concerned that a desire for vulnerability scanning will prevent new languages from entering use because these tools won’t support them.

"Apocolypse" is still a pretty strong word for failing to break into a market because your product doesn't meet the user's requirements.

Re: The Infosec Apocalypse

#6

Post by novok » Thu, Sep 17, 2020, 7:26 AM UTC

Whee more compliance calcification that misses the point to slow down your large competitors with.

Re: The Infosec Apocalypse

#7

Post by Mountain_Skies » Thu, Sep 17, 2020, 7:37 AM UTC

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 and the .net family. None of them are particularly helpful in getting this information to you. They have their marketing checklists and information deeper than this can be hard to come by from the salespeople. A few were scared of letting us have this information at all once they knew it was for a competitive analysis. That's a sign that they take a long time to support new language versions.

In many companies adoption of new language versions happen organically at the developer level, often within days of the new version being released. Even if the system admins try to press the brakes a bit on deploying the new version on production servers, the pressure is there for it to happen. SAST vendors typically are not going to be able to keep pace, which will make your developers unhappy or even give them an excuse for not using the expensive tool you purchased.

Re: The Infosec Apocalypse

#8

Post by jerome-jh » Thu, Sep 17, 2020, 7:39 AM UTC

Static analysis is coming to FOSS as well. There is no mystery tech behind that. Compilers actually do quite a bit of analysis: see Rust. Of course FOSS tools will probably have rougher edges, but the entire field will commoditize in the coming years. There are already a number of competing tools as mentioned by the article.

The usual FP vs IP argument is not relevant: the LLVM intermediate representation is FP.

Re: The Infosec Apocalypse

#9

Post by pubkraal » Thu, Sep 17, 2020, 7:43 AM UTC

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 over your product's security, really, and the tooling really makes it a lot easier.

Re: The Infosec Apocalypse

#10

Post by zxcmx » Thu, Sep 17, 2020, 8:03 AM UTC

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.