Over Half of Software Fails First Security Tests 145
An anonymous reader writes "Even with all of the emphasis on writing software with security in mind, most software applications remain riddled with security holes, according to a new report released today about the actual security quality of all types of software. Close to 60 percent of the applications tested by application security company Veracode in the past year-and-a-half failed to achieve a successful rating in their first round of testing. And this data is based on software developers who took the time and effort to have their code tested — who knows about the others."
Reader sgtrock pointed out another interesting snippet from the article: "'The conventional wisdom is that open source is risky. But open source was no worse than commercial software upon first submission. That's encouraging,' Oberg says. And it was the quickest to remediate any flaws: 'It took about 30 days to remediate open-source software, and much longer for commercial and internal projects,' he says."
That's great. (Score:4, Insightful)
Now they need to test the users.....
Re: (Score:2)
Testing the users might make sense if the Operating System had a reasonable security model. If you can't easily restrict a program to a small subset of your machine, you're forced to trust code you didn't write to get anything done.
Nobody should blame the users, if the OS sucks.
Re: (Score:3, Interesting)
> Nobody should blame the users, if the OS sucks.
Agreed. And most OSes out there suck in this respect (OSX, Linux, Windows).
FWIW Windows Vista and Windows 7 kinda suck less - since they actually have some sandboxing with IE8.
Ubuntu has apparmor sandboxing of firefox as an option that's turned off by default, and even if you turn it on it's not sandboxed enough I
Re: (Score:2)
Cool... some good ideas in here... I'll read this a few times to let it sink in.
Re: (Score:3, Interesting)
Yes, the registry sucks, for many reasons.
Yes, better defaults could have been chosen 2 decades ago.
Now things have changed, and any system that doesn't let limits get set per task is insufficient. The current choices now are insuring 2 more decades of pain. I'm trying to educate people on the better options available, so that a better choice gets made.
It's now necessary to think of security with a much finer grain. The user is no longer the natural dividing line. It needs to be per task instance.
Re: (Score:2)
Of course MS isn't going to let go of the Registry - it would break most applications. No doubt it would be great for Linux because Windows wouldn't be able to run Windows applications either.
Re: (Score:2)
Compatibility (with their own lockin) is their biggest selling point, but because of design flaws (like the registry and countless others) also their biggest weakness...
Re: (Score:3, Informative)
I agree to the extent that compatibility is an important selling point and it also limits their ability to change their OS.
I'm not so willing to concede that the registry is an example of a design flaw. You have to consider the design within its context. For an explanation of why the registry was created and a discussion for and against it see http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx [msdn.com]
Re: (Score:3, Interesting)
The referenced defense of the registry is an article that mostly discusses the weaknesses of Microsoft implementations of ".ini" files, and many of those weaknesses are due to Microsoft design features I consider distinctly suboptimal. I'm perfectly willing to agree that the registry might be better than a botched implementation of rc files, but that is hardly a convincing defense.
Moreover, even if the registry was the right idea in the 16-bit days, that doesn't mean it's not a problem currently. The b
Re: (Score:2)
Don't be ridiculous. The applications barrier to entry doesn't exist and all that the competitors need to do is come up with a killer app and Microsoft will die. Or so people tell me on here repeatedly, ignoring all the Windows only apps and drivers that trap people into using it. The fact the Microsoft themselves have to provide a Windows XP mode tells you all you need to know about how bloody hard it is to shift Win32. Apple may have made inroads but I wonder how many dual booting Macs there are or Ma
Re: (Score:2)
Had you fully read my comments you'd know that I already discussed the "biggest strength and weakness" of Windows (as did Bert64 before me).
Unix/Linux has its configuration problems too.
Re: (Score:2)
The registry has ACLs. That's why many badly written games/apps need users to run as administrator - they need the permissions to change parts of the registry that they shouldn't be changing.
And there's HKCU vs HKLM.
Windows also has %USERPROFILE%\Local Settings and %USERPROF
Re: (Score:2)
like an operating system that keeps ALL settings, from kernel level security stuff to the users font setting in a game program in the SAME FILE
Err... kernel level security stuff is generally in HKEY_LOCAL_MACHINE, which is stored in %windir%\system.dat. User fonts settings in a game should be in HKEY_CURRENT_USER, which is stored in %userprofiledir%\ntuser.dat. Totally different files.
It's already per-user (Score:2)
FYI, the system-wide registry hive (HKEY_LOCAL_MACHINE, or HKLM) is stored in a different file than the per-user registry hives (HKEY_CURRENT_USER, or HKCU, is stored under the user profile directory).
The complaint that each registry hive is all in one file is still somewhat valid (I kind of like having a centralized tool for changing configuration settings, which is a lot easier when you have fewer files containing the settings) but only on Win9x was the entire registry stored in a single location.
Addition
Re: (Score:3, Interesting)
For secure software, isn't it just a bit subjective? These tests were submitted by people who NEEDED to have their software tested. Much of the software out there doesn't deal with sensitive data, and much of it is too simple to serve as a system security risk, and it isn't submitted. So you this 60% figure doesn't really mean much. Most software isn't submitted for security checks and never needs to be.
This article is FUD, and the necessary details are not explained. Meth
Re: (Score:2)
Sure, software security doesn't matter, if the software never takes external inputs that could be controlled by a third party.
That's a good, what, 2% of software?
Re: (Score:3, Insightful)
Your viewpoint is a little close-minded. Most software written is never even sold. It is mainly in-house custom apps in companies where it would be pointless to try to exploit it because there are easier ways to get the data. And how about the software that runs completely closed on microcontrollers that are in every single product sold today?? Think before you post. :)
Re: (Score:3, Interesting)
These tests were submitted by people who NEEDED to have their software tested.
I think the software submitted for testing is actually more secure than the average software, because it's made by people who actually know about the problem.
Much of the software out there doesn't deal with sensitive data, and much of it is too simple to serve as a system security risk
All web sites need to have good security. Without good security, you can get all sorts of hijacking attacks, where systems that seem harmless are abused to mount attacks on more sensitive systems.
The biggest problem with security is the degree it is underestimated. Everyone thinks it's somebody else's problem. Collectively though, the web is a one huge
Re: (Score:2)
Also, how did they come to be testing open source software... Was it submitted by the authors for testing? I suspect not, since the testing process will cost money... Or did they simply download it and decide to test it arbitrarily? If the latter, then the open source software in question doesn't fall under the "needed their software tested" category...
Re: (Score:3, Informative)
We scan selected open source projects on a pro bono basis and reach out to the project teams to share the findings with them.
Disclaimer: I work for Veracode and was a coauthor of the report.
Re: (Score:2)
The flip-side of course is that if the company is submitting their code for security checking, they're paying at least some attention to security. The company that doesn't care may have many many more vulnerabilities.
Re:That's great. (Score:4, Funny)
Of course, 60% of the apps they tested were web applications, leaving 40%...
(Yeah, yeah, it's unlikely that the only apps that failed were web apps, I just thought it a spiffy coincidence that the % of apps that failed testing also equaled the % of web apps tested.)
Secure web app design is HARD (Score:4, Insightful)
I know you meant it in jest, but there's a serious point there.
First, having written a number of small utilities, and some larger GUI-based tools, I have to say that web app design is fundamentally more difficult primarily because you have a number of specific challenges in this area that only apply to them.
Not only do you have to deal with all the usual problems, but you also have to deal with XSRF, XSS, and so forth. This is because you are you have a program which is generating HTML code as output, not merely a nice UI that is the product of the code, and this is happening in a stateless environment so information is somewhat limited in the interaction well beyond what it would be normally. Furthermore, authentication is more difficult in a stateless environment, especially where multi-tier systems are involved.
Most people don't appreciate how easy these are to mess up and how hard they are to fix when a developer creates a project without adequate thought to security in the first place.....
Re: (Score:2)
Why? Surely, if I was going to send my software for external security testing, I would first test it in house, both more cheaply and less humiliatingly. This is not 60% of all software failing, this is 60% of all software sent for test failing. This suggests that in-house testing is remarkably badly thought through.The sorts of the sorts of tests that Veracode are going to do should be predictable - shouldn't you run them yourself before submitting the software?
Re: (Score:2)
Really?
If anything I'm more stunned that 40% of code sent in didn't have any major flaws.
It isn't easy to write secure code.
I do some amateur testing for some of my friends web apps (looking for all the common ones which I'm fairly familiar with, SQl injection, XSS, various code execution fuckery etc) and it's rare to be able to hand back a list shorter than my arm and that's when they're actually writing code with security in mind.
Re: (Score:2)
I don't mean that crappy code is ok.
I'm just trying to say it really is remarkable to be able to turn out any non trivial body code even with extensive testing which has no detectable flaws.
I'd have expected it to be far less than 40% of code getting through that gauntlet.
Of course unless they prove the code (and even then...) there almost certainly is flaws still in there.
What emphasis on security? (Score:5, Insightful)
I thought the only measure of a project was whether it makes the deadline.
Bolting On (Score:4, Insightful)
As Bruce Schneier has said, trying to bolt on security to an existing product or application can be very difficult and time consuming. Sometimes you even have to redesign things. Designing for security and using secure coding practices from the beginning, however, makes it much, much easier.
Re: (Score:2)
And nearly 90 percent of internally developed applications contained vulnerabilities in the SANS Top 25 and OWASP Top 10 lists of most common programming errors and flaws in the first round of tests, Oberg says.
It doesn't matter how much you redesign things, if you fuck up the routine stuff.
Re: (Score:2)
If the design is good, you can fix the bugs. If the design is fundamentally flawed, you
need to throw it out and start again. There is a difference.
Re: (Score:3, Interesting)
When it comes to security, not necessarily. A good design of classes for the purposes of readability and maintainability does not necessarily mean it's easy to fix a security bug. These are often completing design choices.
The two biggest errors cited by TFA were cross-site scripting and SQL injection. Generally, XSS can be fixed if you had a decent design--just filter your inputs better. SQL injection even more so. In my experience, good languages have database libraries that make it easy to use placeholder
Re:Bolting On (Score:5, Interesting)
For another encryption example, look at how windows and linux implement user password hashing...
Linux takes the plaintext password via an input channel (ssh, telnet, gdm, local console etc), passes it to PAM which loads the corresponding password from the shadow file, encrypts the user input with the same algorithm and salt, and compares the output. The backend (pam, encryption cipher) can be changed without affecting how the frontend, making it easy to use a different encryption algorithm as increases in computing power, or discovery of cryptographic flaws, renders the old ones insecure.
Windows, in a somewhat misguided attempt to prevent plain texts being sent over the network, effectively uses the encrypted hash (yes its more complicated than that, but the general idea is that only the hash ever gets used and the password isnt sent in the clear - unix solves this at a different layer by using encryption of the plaintext password such as ssh)... Because of this, the hashing algorithm is difficult to change. Older windows used lanman which is laughably weak, while modern windows uses ntlm by default which is somewhat stronger but not great... However, modern windows still has lanman support for compatibility reasons, and until vista/2008 it was still enabled by default. If they change the hashing algorithm, then they will still have to retain the old ones for quite some time in order to have compatibility, and also change the protocols to handle a third possible algorithm.
The fact that you can use the hash without cracking it first is also a design flaw, this isn't possible on unix or anything else i'm aware of.
Re: (Score:2)
Re: (Score:3, Insightful)
Designing for security and using secure coding practices from the beginning, however, makes it much, much easier.
Sure it does... but that sort of design takes money and expertise. More often software is dreamed up and planned in ad hoc meetings. For example, a person in marketing decides it would be a great idea if their customers can get updates on their phones and Nitwitter accounts. In a 4PM meeting the marketer proposes it to his boss as a necessary value-add function without which the competition woul
Re: (Score:2)
Sure, bugs can always be introduced, and some of these will open security holes. But as long as the fundamental design conforms to a sensible security model, this isn't a big deal. That type of bug can be found through additional code review. (Note that testing is *not* a method to find security bugs.)
Re: (Score:2)
That type of bug can be found through additional code review.
Every bug can be found through enough additional code review. The problem is, it's slow and expensive.
Re: (Score:2)
So, what's your point? Bugs are hard to find. Bugs can be fixed, a broken security model cannot.
Re: (Score:2)
It's software, there's nothing that can't be fixed.
Re: (Score:2)
Bugs can be fixed without impacting operation/compatibility...
A design flaw cannot.
Re: (Score:2)
No. Both design flaws and bugs can sometimes be fixed without impacting operation/compatibility and sometimes they can't.
But we weren't talking about the consequences of a fix, just whether it can be done.
Re: (Score:2)
99% of it does not. Internally designed stuff in a company is usually the biggest messes there are. They were started by some mananger that was handy in VB 6 years ago and then perpetuated. nobody is ever given time to take a year and rewrite it, so everything is not even bolted on, it's slapped on with duct-tape.
to fix this we need to force managers to understand that software is not easy nor fast. Some say it takes education, I say it needs kneecaps broken.
But then I'm a humanitarian.
Open source doesn't necessarily mean dangerous (Score:3, Insightful)
I know of at least one rather large and well-known company that doesn't use OSS because of "security", yet voluntarily continues to use IE6.
That sort of thing really pisses me off.
Re:Open source doesn't necessarily mean dangerous (Score:4, Informative)
Quite the opposite. OSS is often far more secure than its "commercial" counterpart, for the obvious reasons.
1) No deadline. OSS is usually "done when it's done". Most OSS software I know is in perpetual beta, never reaching what its maker would call a "release state", but offers at least the same level of security and stability (if not better) as its commercial counterpart. Simply because there is no date we have to push something out the door, secure or not, ready or not, we have to make it for christmas (or for the new Windows version).
2) No need to "sell" the software. You needn't dumb down and strip security so potential customers accept the level of burden security adds to the fold. Security is never free. It always comes at the price of overhead. When you have two software tools available, customers will pick the one that is more "accessible". Which usually also is the less secure one. Because security often adds layers of additional overhead (either to you, the user, slowing you down and requiring you to enter passwords or access things in a certain way, maybe even with additional tools instead of from "inside" the tool you're mainly using, or to the system, meaning your software will run slower).
3) Peer review. Your code can easily be reviewed by thousands of "hackers" trying to find an easy way into your system, instead of having to poke at decompiled code. If you can read the source, far more people are able to poke and prod at it, resulting in more secure software instead of less, because security holes get found faster and, in turn, fixed faster. By the time you start using the product, a few months after its release, you may rest assured that all the easy to find security holes have been found by hobbyists. With CSS you often need experienced ASM cracks to dig those holes up, resulting in fewer people able to look at those holes and thus a slower patching cycle.
Re: (Score:2)
a) While all you say is more or less true, that applies to big well known OS projects only. Obscure little one/two man projects don't have that big of a peer review. If those projects have few users, you can live with critical security holes for years without then even being known.
b) Extra large OS projects have the chaos factor against them. When a security hole is patched on some Linuz distro: where does this apply? On Ubuntu? Is this present on Kubuntu as well? Wh
Re: (Score:2)
Re: (Score:2, Insightful)
Re: (Score:2)
...that applies to big well known OS projects only. Obscure little one/two man projects don't have that big of a peer review. If those projects have few users, you can live with critical security holes for years without then even being known.
How secure do you imagine that obscure little one/two man proprietary, closed source projects are? The comparison doesn't just apply to big, popular OSS projects. Other things being equal, open source projects will tend to be more secure--if for no other reason, simply because people tend to be more careful when they know others will review their code. However, you're quite correct in pointing out that there are other factors than just open vs. closed, and it's important to factor those in as well.
Re: (Score:2)
It's typically because whoever is in charge is incredibly under-educated. Probably their CTO or CIO really knows nothing at all, and then filled the ranks below him with yes-men that knows as little as he does.
At the bottom you have the guys wanting to get things done and secure, they pound their heads against the wall.
Re: (Score:2)
And let me guess... their IT department would claim that open-source software is too difficult to test and administer patches remotely and keep updated?
Undefined requirements (Score:2)
There is no requirements document for security that you can follow and guarantee that your application is secure. You're really trying to anticipate all the ideas other people may have about compromising your code. In general, this is impossible to achieve, so you do the best you can.
Re: (Score:2)
There is no document because such a document would be outdated the moment you wrote it.
I write security guides and tips for a local computer magazine, based on developments in the malware industry. It happens, rarely but it does, that I have to retract my articles at last minute and rewrite them because what I wrote simply is not true anymore. What I wrote a year ago is certainly no longer true. Tips I gave 6 months ago are not offering security anymore. And what I wrote 3 months ago might still hold a hint
Re: (Score:2)
There is no document because such a document would be outdated the moment you wrote it.
That's why you put it on a Wiki!
Re: (Score:2)
You want to base your security guidelines on a wiki? And be held responsible for its implementation? Are you nuts?
Re: (Score:2)
"There is no document because such a document would be outdated the moment you wrote it."
I agree. My point was that we shouldn't be surprised that many applications are not secure because it's an open-ended problem.
Re: (Score:2)
Then you're approaching security as if it were a technology. It's not; it's a science. If you write instead about the application of security principles, you won't find yourself having to retract anything.
Sure, a particular use case might become less relevant over time, but it can't become wrong unless you misunderstood the underlying principle to begin w
The other half (Score:2, Funny)
And the other half isn't even tested.
Re:The other half (Score:4, Funny)
Nah, the other half crashed when pitted against the security test suite.
Well now (Score:5, Informative)
That's extrapolating a bit much, isn't it? And scanning through the article, they don't even name the sample size, just percentages.
And yes, they mention that its only the stuff that they test, "so imagine what the rest is like". Well - thats it though, if someone is professionally developing with security in mind, they probably know how to test it in office or know somebody who can. Thus - no need to pay this corporation to test something you can do yourself.
If you are developing with security in mind - but aren't sure exactly what you're looking to protect against - THATS when you go to companies like these.
This is a pretty much skewed data source (probably a slashvertisement for them, too), and is the only study of its type. Take it with a weeks worth of salt.
Re: (Score:2)
Well - thats it though, if someone is professionally developing with security in mind, they probably know how to test it in office or know somebody who can.
Independent security validation is the only way to verify that your approach to security works in practice.
Re: (Score:2)
That's extrapolating a bit much, isn't it? And scanning through the article, they don't even name the sample size, just percentages.
I was wondering about selection bias, and, yes, investigating the company that did the research they appear to specialise in analysing native code (e.g. C or C++ applications) running under Windows. My guess is that a lot of the more security-conscious developers have moved to other environments (interpreted or JIT-compiled code and/or Linux), so they're left analysing the dre
Re: (Score:2)
I made my submission after first seeing a story in El Reg. While I saw it in several other places, I thought the Dark Reading story was a bit better in highlighting the findings than most. You're right, though. It's very light on the methodology. The press release [veracode.com] on VeraCode's site has a bit more information:
Security is no selling point (Score:5, Interesting)
It just is not. Actually, quite the opposite: The better your security, the more your potential customer will be put off by it.
Users do not care about security until it is too late (i.e. until after they got infected), and only then they will bitch and rant and complain how insecure your piece of junk is. If you, otoh, take security serious and implement it sensibly, they will bitch and rant already at install because they hate the hoops to jump through and the obstacles to dodge to make your software "just work".
Security is the antagonist to comfort. By its very definition. No matter where you look, security always means "additional work". Either to the user, which means overhead to his work, or to the program, which means it will invariably be slower than its competing products.
Thus security is not only an "unnecessary evil" when selling your product. It is actually hurting you when you try to convince someone to buy your stuff. Your software will be slower due to its security "burden", and it will be less comfortable to the user. The user does not see the glaring security holes when he buys the product. Only after, when the product bites him in the ass because it opened him up to an attack. But by then, he will already have paid for your product. And he will have bought your product instead of the more secure product your competitor offered, because yours was faster and easier to use.
Re:Security is no selling point (Score:4, Insightful)
Protecting against SQL injection attacks, XSS, buffer overflows, and validating user input does not put off users.
Re: (Score:2)
Yes it does. It makes your product later than the fast & slopper competition.
Re:Security is no selling point (Score:4, Informative)
Actually, good security would be a GREAT selling point, if someone actually implemented it.
Security is the ability to run code without unwanted side effects. Windows, Mac, Linux do not offer a simple way to do this. The closest you can get is either Sandboxie on Windows, AppArmor on Linux, or setting up a VM per program.
If you offered a way to specify the limits of side effects on an application before and while it runs, you could make a ton of people very happy. I suspect there is some money to be made there as well.
Re: (Score:2)
It's not an either/or thing. Secure software is often the *easiest* to configure. It's when configuration is difficult and prone to error that people make mistakes or start using default configurations.
For example, when a service is installed on a system many installers do not have procedures for configuring the firewall. It may be a range of ports that's needed, or some access to a particular IP address. So people install the software and it doesn't work. They read something on the Internet that it's a f
Re: (Score:2)
It depends on the product, but there are indeed corporate customers who have policies disallowing them from purchasing / deploying software that does not pass independent security audit.
It's a mixed bag, and it depends on the market you're in. For some types of software, security is a non-issue. Security is like usability. You can always improve things, but at some point you have to say "up to here, and no further".
Re: (Score:2)
The better your security, the more your potential customer will be put off by it.
If, by “better”, you mean more intrusive, controlling, cumbersome, slow, and restrictive... then yes. Of course they will be.
But if, by “better”, you mean less intrusive, controlling, cumbersome, slow and restrictive...
Re: (Score:3, Informative)
Your entire rant is based on a false premise. In most cases, security actually increases "comfort" or "convenience." It's damn inconvenient to use a system which crashes, misbehaves, and needs to be frequently rebuilt due to security problems. Removing buffer overflow vulnerabilities from your software in no way inconveniences your users.
Authentication is perhaps the only piece that sometimes is inconvenient. Just typing your username to log in is more
Re: (Score:2)
The problem is, all those nuisances will not surface until you have the product in a "productive" environment. Most products look quite nice in laboratory conditions (i.e. at demonstrations), even if they're crash prone, insecure and incompatible.
By the time those crashes, reinstalls and "wtf did it do now" moments appear, management will already have signed the payment for the piece of junk you'll be tied to for the next decade.
Re: (Score:2)
I think there is a political issue which disproportionally elevates the importance of security - it's a talking point against Windows.
Security firm says security is an issue (Score:5, Insightful)
Hmmm . . . there's a word for that . . . XKCD, can you help me?
http://www.xkcd.com/703/ [xkcd.com]
Re: (Score:2)
What about commercial open source software (Score:5, Informative)
So lots of comparisons between open source and commercial software; however there is a lot of open source software that is sold, i.e. commercial. In addition it has been shown that most of the code for the Linux kernel was developed by people who were paid to do it by Red Hat, IBM, Intel and others. Does that mean that the Linux Kernel is commercial software.
May be the article should refer to closed source proprietary and open source software.
The article reads as if the author does not fully understand the how Open Source software is developed and is just a large advert (a.k.a. press release) for the auditing software.
Re: (Score:2)
The comparison should really be application to application regardless of the open/closed commercial/non-commercial categories. There's no inherent relationship between these categories and security.
80-20 (Score:2)
They get paid to find security holes (Score:2, Interesting)
Code has bugs... so don't trust it. (Score:2)
Code has bugs, it always will. You need to reduce the attack surface, why not reduce it all the way down to the kernel of the OS? If you don't need to trust any of the users programs with the security of the whole system, you've solved a lot of problems.
Don't trust the users? Not a good idea. The users are the administrators these days.
Don't trust the internet? Well... it's a communications medium, just a set of tubes.
Don't trust the programs? Great idea!
Re: (Score:2)
Code has bugs, it always will.
Really? I defy you to find a bug in my implementation of /bin/false. :)
What is true is that the chance of a bug appearing grows exponentially as the code increases in complexity, so that for any program of moderate or greater complexity, the chance that one or more bugs exist is near certainty, but I wouldn't be posting on slashdot if I didn't enjoy the occasional moment of nitpicking pedantry... :)
Re: (Score:3, Insightful)
The reason users mess things up is that they have bad tools. There is no simple way to run something in a sandbox.
sometimes security doesn't matter (Score:2)
Sometimes security doesn't matter, esp. with regard to the "internal project" stuff mentioned.
Of course, this is the area that basic utility scripting is used, you and perhaps one or two others are the only ones using it, you already have access to any other system you could get via a cross scripting technique, access to any DBs you'd get with a SQL injection, etc.
In other news... (Score:4, Insightful)
Not a shocker (Score:3, Interesting)
Coming from the systems integration side of things, I don't view this as a surprise. Developers are great at writing software, but in my experience they have no idea about how the platform they're deploying it on actually works beyond the API function calls they make. This leads to internal applications that I have to throw back because part of the requirements are, "User must be a member of the Administrators or Power Users group." Most dev guys just don't get that it's very dangerous to give the end user full rights to an Internet-connected Windows box. There's just too many holes in Windows to safely allow it.
To be fair, there are a lot of reasons for stuff like this...not the least of which is deadlines for deploying "something that works." I've been there on the systems side too...scrambling at the last second to get hardware and operating systems deployed because of a deployment date. There are also a lot of apps coded in C++ and other unmanaged languages that open the system up for all sorts of buffer overrun attacks. Not much you can do there except vigilant code checking.
I think a little education on both sides of the fence would be useful. Developers should get some kind of training in "systems administration and internals for developers" and systems guys should definitely be educated in what holes are safe to open up on their systems. (That's a big cause of this too -- there's a lot of low-skilled systems admins out there who take the developer's instructions at face value without checking to see if full access is really needed.)
Re: (Score:2)
Why force the developers to worry so much about security? Why not instead provide a way to have a contract with the OS, which limits side effects to a known set of limitations? That would save a lot of grief, and let the developers get on with it.
Re: (Score:2)
The contract system is called capabilities, and it was first described in the 1960s. It's simply a kernel owned list of things a process is allowed to do.... if it's not in the list, the process doesn't get to do it.
Programmer skill is great, but you can't blame the programmer for bad tools either.
Re: (Score:2)
Mod parent up. I come from the same SI background and now running a programming shop. What dumbfounded me were the folks with CS degrees that really had no idea how the networking/systems side worked. I can remember a few times they'd call me over after working half a day or more trying to figure out why something in their code wasn't working only to have me take a look and in less than 30 seconds figure out it something on the server wasn't running or there was a network configuration problem.
"remediate"? (Score:3, Insightful)
Obsolete? (Score:3, Informative)
The conventional wisdom is that open source is risky.
Does anyone believe that anymore, other than journalists quoting other journalists and PR people?
I did some google searching, trying to find when that old FUD campaign started. It seems to not show up much until 1998.
The 12 year old advertising/FUD campaign is getting kind of tired.
60% !!! (Score:2)
Encouraging? (Score:2)
The conventional wisdom is that open source is risky. But open source was no worse than commercial software upon first submission. That's encouraging
...um, I’d have started with the opposite premise, that open-source is safer. In light of that premise, I think their findings are somewhat discouraging... except,
It took about 30 days to remediate open-source software, and much longer for commercial and internal projects
Now that’s encouraging.
I am a professional softwaredeveloper myself..... (Score:2)
Security (Score:2)
Back when I was in charge of hiring new programmers for a web development shop, the very first thing I'd do when I got a resume would be to load up the applicant's personal website, if he had one.
No, I didn't look at the aesthetics of the site. I didn't care about the cleanliness of the HTML. The implementation language and web framework didn't matter. I had more important things on my mind: I would find a form, and type hello world' -- ; SHOW TABLES. If the site misbehaved, I'd toss the resume in the trash
Re: (Score:2)
Attention to correctness is the bedrock trait of a good developer. Everything else comes second; security is just one property of correct code.
I disagree. This is pure lip service. Everybody wants secure code, but nobody wants to pay for it. So I infer that security and quality is not important. Whenever I submit a realistically estimated cost/time plan I can be sure that I won't get the bid. So cheap and fast, everything else comes second, or third, or fourth.
A situation I experienced myself.
Company, which developed medical devices. Project manager: Make sure, that the gui looks nice. Me: Cannot do it, somewhere the is a problem, which caus
uhhh (Score:2)
So Veracode is missing about 40% (Score:2)
It seems to me that a through test would initially flunk pretty close to 100% of all software. So this means Veracode is too lenient by about 40%.
Re:As misleading as 'Show all warnings' (Score:4, Insightful)
I've worked with managers and developers that want to eliminate all the warnings in the source.
There’s a good reason for that, and it’s not as petty as you think.
Warnings exist to let the programmer know that the actual behaviour might not be what the programmer thought was most intuitive. If it’s implicitly casting a float into an int, you damn well better know what that means and what effect it’s going to have on your code... it means that 1/2 == 0, for starters. Similarly, there’s absolutely no reason why you can’t use (count = 5) as an expression, except that its value is always 5, not true or false as you may have incorrectly thought.
Lazy, sloppy, or inexperienced programmers are going to fall for these sort of pitfalls. Experienced, careful ones won’t nearly as often. But if you force a lazy, sloppy, and inexperienced programmer to learn why the compiler is giving a warning and eliminate it, he’s going to end up slightly less lazy, more careful, and with a little more experience than he started with, because he’ll hopefully understand the warnings by then and know what the code is actually doing.
Re: (Score:2)
Three point five point FIVE?
We’re up to version 3.5.8. Please do try to keep up.
Re: (Score:2)
Scratch that... 3.6 has been out for a month now. I rarely restart this computer, so it hadn’t told me to update yet.
Re: (Score:2)
Scratch that... 3.6 has been out for a month now. I rarely restart this computer, so it hadn't told me to update yet.
I'd update _now_ if I were you. I didn't notice the problem either, but then I visited an old bookmark to a bittorrent site that's now defunct and got rooted and I got myself an annoying piece of adware installed (ironically entitled "Windows XP Antivirus").
Versions of FF only a few weeks out of date are now being actively exploited by the bad guys. Keep up-to-date.
Re: (Score:2)
I already did.