back to article Free tool aims to make it easier to find vulns in open source code

DevOps outfit SourceClear has released a free tool for finding vulnerabilities in open-source code. SourceClear Open is touted as a means for developers to identify known and emerging security threats beyond those in public and government databases. “Developers are being held more accountable for security and demanding tools …

  1. Scott Broukell

    So, erm . . . what should I use to determine any vulnerabilities that might be within Source Clear Open? Also, there's a hole in my bucket dear Liza, dear Liza . . .

    1. Charlie Clark Silver badge

      So what? If the scans of your code help you identify flaws in your own, open source code then that's a win. Static code analysis can pick up a lot of issues. I've been using Quantified Code for about a year now and am very pleased with it.

    2. Michael Wojcik Silver badge

      what should I use to determine any vulnerabilities that might be within Source Clear Open?

      Point .... missed!

      Of course, per "Reflections on Trusting Trust", you should never use any software, ever, for anything.

      Or, alternatively, learn something about threat modeling.

  2. Anonymous Coward
    Meh

    DevOps approach to Security

    I think I get why this is filed under Hype DevOps... because it plays to the idea that you can just write a ton of bloated crap code, run it through a few tools like this, and get secure software. Nope. You get... ImageMagick.

    That's not to say you shouldn't bother with automated tools like this. But if they find ANY real security flaws, I'd say it's not enough to plug those holes. The software in question needs a thorough going-over.

    1. Captain DaFt

      Re: DevOps approach to Security

      And if it doesn't find something, it's safer to assume it doesn't cover all contingencies (Those pesky unknown unknowns), than to assume your code is 'bug free'.

      No such animal for anything much bigger than "Hello World",

    2. Charlie Clark Silver badge

      Re: DevOps approach to Security

      Static code analysis is no magic bullet but it is complementary and is particularly good at doing the stuff that bores people: it's more eyes but eyes that don't glaze over.

    3. Michael Wojcik Silver badge

      Re: DevOps approach to Security

      Lordy, but you people (Charlie Clark aside) do not understand code analysis.

      Let's get rid of those pesky compiler diagnostics too. They don't catch everything, so they're useless.

      1. Anonymous Coward
        Anonymous Coward

        Re: DevOps approach to Security

        Lordy, but you people (Charlie Clark aside) do not understand code analysis.

        I certainly do. Languages like JS, PHP, Python, Ruby, C/C++ are fairly opaque to static analysis. Fuzzing isn't the answer to everything either.

        Auto-analysis tools are a machine gun approach to software defense; spray 'n' pray. Not a substitute for the (almost nonexistent) engineering that's so sorely needed.

  3. JeffyPoooh
    Pint

    Why not build this checking into the compilers?

    Save a step.

    Probably about time for the language-design boffins to invent a modern computer language with security an inherent part of its architecture. Sort of like "strongly typed", but 'strongly secure' instead.

    1. Paul Crawford Silver badge

      Re: Why not build this checking into the compilers?

      Lets face it, a large number of recurring vulnerability in software written in C due to buffer overrun and misuse of printf() like format strings are ALREADY flagged by compilers like gcc if you use -Wall.

      Problems is your code monkeys have to give a monkey and (a) use those options, and (b) fix them when found.

      The lack of data type enforcement in stuff like javascript and python is a whole other area of ease-of-use against properly thought out code, and guess what suffers?

    2. Roland6 Silver badge

      Re: Why not build this checking into the compilers?

      Been done: Ada - first released in 1980...

      Also as security isn't skin deep, you also need OS's such as the Intel iMax 432 (written in Ada) that actually use the security features embedded in chipsets such as the Intel 432 - much of which has now been incorporated into the x86 architecture, which does beg the question...

      1. Michael Wojcik Silver badge

        Re: Why not build this checking into the compilers?

        the security features embedded in chipsets such as the Intel 432 - much of which has now been incorporated into the x86

        What? The iAPX 432 was a capability architecture. By no means has "much" of its security set been incorporated into x86. That's simply impossible without rewriting applications - there's no way to provide backward compatibility with the trivial and reinterpretable data types supported by a non-capability CPU.

        You can build a capability architecture on top of a largely-non-capability chip; the IBM System i (nee AS/400) is more or less a capability architecture, and moving it to POWER only required some minor enhancements to the POWER architecture. But that worked because the software running on OS/400 was already written to work in a capability regime.

    3. Michael Wojcik Silver badge

      Re: Why not build this checking into the compilers?

      Different beast.

      Many people have argued for stronger static analysis in compilers. Peter van der Linden, for example, criticized the separation of cc and lint. Sometimes compiler vendors do put more static analysis in their implementations; Microsoft has done so a number of times over the past decade or so, as has the GCC team.

      But that's not the sort of static analysis SourceClear does. SourceClear scans a codebase, which can include components written in multiple languages and the systems that implement those components, for known vulnerabilities. So it doesn't just check your code - it checks things like web server configurations, language-engine versions, etc. It gets updated as new vulnerabilities are published.

  4. HachavBanav

    Regarding web site security, you HAVE to check https://owasp.org/index.php/Main_Page "Bible" (include the project Application Security Verification Standard https://owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project)

    ...and I found a nice tool https://github.com/highway-to-urhell/highway-to-urhell that list all answering root URI from your web site (include it in your compilation, execute, remove the vulnerabilities, re-execute...up to it's clean then delete from your project)

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like