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 . . .
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 …
COMMENTS
-
-
Wednesday 11th May 2016 18:38 GMT Charlie Clark
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.
-
-
-
Wednesday 11th May 2016 18:40 GMT Anonymous Coward
DevOps approach to Security
I think I get why this is filed under
HypeDevOps... 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.
-
-
-
Saturday 14th May 2016 13:57 GMT 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.
-
-
-
Thursday 12th May 2016 07:27 GMT Paul Crawford
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?
-
Thursday 12th May 2016 11:43 GMT Roland6
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...
-
Thursday 12th May 2016 19:32 GMT Michael Wojcik
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.
-
-
Thursday 12th May 2016 19:29 GMT Michael Wojcik
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.
-
-
Monday 23rd May 2016 16:31 GMT 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)