81% of developers admit to knowingly releasing vulnerable apps – research
theregister.com
theregister.com
I have never been thanked for delaying a release because of problems I was aware of. Usually it is the opposite, me standing like Gandalf and shouting "You shall not pass!" and management trying to find a way to kill me for it.
There is rarely any cooperation in these matters, it is about who can put more pressure and more foot down and whether I want to risk getting branded as trouble maker.
One contributing factor I don't see people mentioning is that management tends to be absolutely fixated on things that can be easily measured. You can measure timeliness of releases or number of clients or cash flow, but you can't easily measure security, customer or developer satisfaction. With the end result that the things that are important but not easily measurable are getting little to no meritorical discussion.
Where I work, we use Chexmark and Whitesource to scan for vulnerabilities. These get routed to grafana. Then to management. Results are available in git within 15 minutes - allowing the merger to wait until the results are available before merging
Developer satisfaction is measured with a quarterly survey that goes to ALL employees
Customer satisfaction is measured with a different survey
Umm... that has little to do with security? You may or may not understand, but security is a process and those tools are but small parts of that process.
If security could be guaranteed by tools like the above how are we still hearing about security issues at all?
We commonly hear more about "security snake oil" than snake oils of performance (also slippery to define) or usability (another definitional minefield). Why? I think it's because security fits into the Bermuda Triangle of:
1. loose terminology (that we all argue about)
2. no obvious, casually noticeable effect
3. unknown but real risk
The same as UFOs, psychic phenomena, deities, etc.
And we have an industry built around maintaining that mystique.
For an open database to the internet, you will need completely different tools - I speculate network scanning. A bigger problem is running code that DELIBERATELY sends data to an outside source though your proxy.
OS level issues should be managed by a central team that approves the version of OS and EVERYONE installed that EXACT patched OS, and refreshes quickly after patches are released.
I am 100% on your team here, but I do want to point out that what is important to developers is rarely considered important by the business, more that it's a cost of working with developers. There is no objectively correct "Most important" since there are entirely different priorities and perspectives at play.
At some point, liability notwithstanding, you get left with no choice. If someone wants to sink their company with bad software, regardless of how loudly I tell them that's what they're doing, I really have no choice but to hand them the drill and leave them to it.
Well, IMO constant churn of developers who change jobs every 2 years is very adversely impacting quality of the product. When people know and expect they are most likely to be leaving in 2-3 years tops they are not going to stand for what they believe and will be much more amenable to pressure and taking on debt that somebody else is going to be paying.
Now, churn can be easily measured, but its impact on the product or how developer satisfaction contributes to it cannot be easily linked.
>“If an organisation needs an application to be released to make a specific deadline regarding market opportunity or new features, developers are often caught between hitting that no matter what or potentially delaying the fix of critical or high-risk vulnerabilities.” [said Simon Roe, Product Manager at Outpost24]
And:
>... dev teams are often measured by feature output, and security isn’t usually seen as a feature. “Unless security is viewed as a feature, it will be viewed as a tax,” according to Tim Mackey, Principal Security Strategist at the Synopsys CyRC (Cybersecurity Research Centre).
Real engineers don't sign off on a project if they think the building is going to fall apart. If a company starts ignoring security for the sake of profit, developers should react by literally walking out and refusing to have anything to do with the project. Anything else means they share the blame.
A building engineer could probably drop a hint somewhere and have all kinds of inspectors come knocking, but there's no "building code" for software except in very specific cases; it's perfectly legal to develop insecure software otherwise, and to keep that insecurity a secret from users.
One power we all have is how valuable we are in the jobs market. If you’re a decent engineer in today’s climate, you could get a new software job in days. And it’ll take your company weeks to replace you if they’re lucky, and months to bring your replacement up to speed on what you were working on.
The idea that you’re stuck simply working at the whims of management is a self defeating illusion. It is only as true as you believe it to be.
And your manager can't afford to fire everyone who pushes back on shipping insecure code. And its not a black and white thing. There's almost always paths which work for everyone. Actively looking for those paths isn't the sign of a bad employee. Its the sign of leadership.
In my experience people who step into that sort of responsibility don't get fired. They get promoted.
I feel like they actually can, since:
- most people want to get paid and to have a job, not get fired over principles
- therefore, they will bend to the whims of management and release whatever they're told to release
- they don't actually have any sort of leverage, as most developers, and are easily replaceable
Here's a similar post from today: https://news.ycombinator.com/item?id=27629543
It's an indication that engineers know in some cases they are releasing broken software, and management may not be aware. Just look at this page and it's article, developers know about this, because they congregate to discuss how they release broken software, know they should do better, yet don't always tell management about faults in the product. A business shield only protects people when they are conducting business.
I think under those conditions most firms would prefer to own the risk themselves.
The point that you missed, however, is that an employee should not accept the risk but should transfer the risk by notifying the employer. Otherwise, articles such as this are fodder for putting the blame of exploited vulnerabilities squarely on employees who knew of the risk and, according to some of the comments here, plotted not to tell their employers.
It absolutely does. If you hold any legal power to reject a deployment (like a true engineer), then you can sue the company when they hold it against you, so they won’t.
If you do it in any other situation you are just being difficult.
If software developers do that they are just being difficult.
I mean let's be real, in the US you definitely could. Pretty much anyone can sue anyone for anything.
But between suing McDonalds, and suing the close-to-minimum-wage-employee working at McDonalds, which group do you think you would be most likely to collect from in the event you won? Not to mention the public perception of suing an individual McDonalds employee.
No, for this particular example, it would almost certainly not be possible. In the US, employees are shielded from personal liability under the doctrine of respondeat superior.
[citation needed]
Company employees in the US (including software developers) are shielded from personal liability by their companies, unless that liability was created by breaking the law or gross negligence (with the latter being extremely difficult to prove). The company can fire the developer for being incompetent or negligent, but the company would still be on the hook for any damages.
The same is true when outsourcing development to a third-party development house. The client company may be able to sue the development company, but the individual developers would be shielded from personal liability by whoever they worked for.
The only situation I can think of where a developer would be personally liable for buggy or insecure software is if they signed and sealed source code as a professional engineer (this is practically non-existent), or if they were freelancing and contracting with companies directly. In both cases, they would be eligible--and often required by their clients--to purchase insurance against errors and omissions.
I have seen this changing since the introduction of GDPR in Europe. There is a direct cash incentive to avoid data-leaks. Being mandatory to inform of any data-leak and the possibility of fines makes it more clear that security is a business concern not just a technical one.
I'm now looking into one of the Pentest reports. It states that "Header Disclosure" is a low risk vulnerability. If you take it to the extreme then "a lot" of websites are vulnerable. I would question how the survey was carried out and how questions were framed.
That said - the problems being discussed here do happen, I just don't know how accurately the headline represents that.
PMs don't usually care about security really, they also just want to check off boxes. Like my old PM wanted to load test the CDN (AWS) we were using just so that we could check off a DDOS proof box.
I said that load testing AWS was pointless and that we should load test our supporting infrastructure instead and he just dismissed it.
Kinda makes me feel a bit depressed about the state of the industry tbh
I've joined a company that uses nuxt with nuxt-auth, which is incapable of securely (i.e. not) storing tokens. This means access tokens are stored by JS in cookies. So I know the app is vulnerable to XSS, but there is no way to fix it because the author of the tool doesn't think it's important.
Honestly, if developers didn't know they were releasing vulnerable apps, I'd be more concerned.
Vulnerabilities come in all shapes and sizes, and unless you stick your head in the sand you end up doing "vulnerability management", ie deciding which ones are release blockers and which ones should be treated like other bugs and defects in your app, and what to do about ones that are outside your control in eg platform functionality. Not to mention CVEs in your dependencies that might surface any time.
All people around me that are not involved in tech have so many crap apps on their phone and think I'm weird for not even having Google Play or any other Google service on my phone. It's kinda like that xkcd on voting software, if you work in the business, you know how bad things really are.
How do you know? Android and iOS apps are much better sandboxed than desktop applications (which usually aren't really sandboxed at all). I would guess the chance of phones getting compromised is much lower than for the average desktop.
But that is besides the point, because a hardware token is almost impervious to attack. One would have to engineer a very specific bit of software or hardware and have physical access to this token. Requiring a phone app to confirm a payment made on your desktop just increases the attack vector.
The desktops I see on a daily basis don't have only a browser and office application installed.
I'm not sure which phone or OS you are using, but almost all smartphones have some kind of TPM or TEE nowadays. FWIW, the banking app on my Android phone makes use of that through the KeyChain API.
It usually takes somebody with a bit of seniority to push these issues to the front, as the management usually only can see visible problems.
We’re still achieving our NSIS certification. Not because we’re secure, but because all ways to measure IT security come down to documentation, and, we certainly have that part covered.
I guess that somewhere, shops that weren’t already trying to do their best to be as secure as possible with what resources they have, are going to do a GDPR risk analysis and go “hmmmm, maybe we should encrypt those data” or “hmmm, maybe we shouldn’t host our backup locally” or something along those lines. But at the end of the day, you’re still massively understaffed and on insane deadlines and working with tools that simply aren’t designed to be safe.
I think the biggest issue is the illusion that all the documentation and focus will somehow make it safe eventually. It won’t. Not compared to not putting your powergrid on the internet.
We had a big issue with our pools a few years back. For some reason, someone decides to put the pool controls on the internet, so that janitors didn’t have to go work some ledgers or whatever they did before. Of course it was horrible, because pool companies aren’t going to hire the experts or spend the time or money they need to make it as secure as it should be. But the biggest issue I have with it, is why it was done. You may think it was to save money, but the subscription to have the online pool controls were more expensive than having people just to check on them, and it’s not like an organisation with around 150 different buildings aren’t going to have janitors out there anyway.
So there was simply no reason, and nobody really wanted the system, it just came with the pool. Then eventually one of them got hacked and the practice stopped, but do we really need to put these things online?