I just came across this article in Slashdot.
I’m not a coder, so i have a question about this. If someone writes code for an application, he or she doesn’t know how the code could be abused? Or does one have a “general” idea, but not an exact?
Again, i don’t know how to write code in any language, so if somebody could explain this, i could learn something new.
I’m not a security expert but this is my perspective as a security hobbiest…
Security is a completely separate field that sits on top of knowing how to code and even the most security conscious devs are totally inadequate at doing security. It’s an entirely different mindset in a constantly evolving field requiring specialized tools, obscure information and being well tied in.
That isn’t to say devs shouldn’t do their best but it’s hard to fault them for not wanting to split their time between totally separate paths even if they’re complimentary. That and people tend to suck at paths they’re not interested in. If i’d take a swing at what the general rules for devs should be…
There’s also how these apps are run by default. I think there needs to be a major shift toward containerization and user friendly alerts/management for which apps can do what (I’m not talking about Flatpaks and Snaps btw which are designed for compatibility, not security despite the hype). For example what’s in my clipboard should only be accessible to an app if I paste with that app in focus. It’s a long road ahead.
So if i understand correctly, there’s the code that’s been written by a dev.
That code is then looked at and used by security experts, who in their turn, point out to the devs, the flaws they’ve found.
It’s then up to the devs to solve these flaws or not. Meaning, if they"re willing to implement/adapt their code to fix the problems.
I think that implementing the fixes in the code can be problematic? Code to be rewritten?
But isn’t that the end goal? Having a decent and hopefully secure product? Nothing is 100% secure, i get that, but to say it’s insufferably boring, for instance, looks to me like your not doing your job very well. Or you don’t care what happens to the product, after you release it.
Again, i have to say, i’m not a coder. I react from a user perspective.
As a side thought; Is there a language that’s easy to understand/learn for absolute beginners?
When good code is written, test cases are written with the code to test the code. Security practices have found their way into these test cases. The way code is looked at today is not the same as it used to be.
The are security practices that are being put place. For example, code reviews, as mentioned above. This could be as simple as two coders working on the same code, one coder reviewing another s code, etc. There are also security programs now that test code. We’ve come a long way in a short time.
Most everyone has heard of DevOps, SecDevOps is a little newer, but adds security focus to coding practices.
Back to the beginning. If you are coding and are not writing test cases, then you won’t know what happens when someone puts invalid data into a web form, as an example. Python has several test modules, such as unittest or the more common PyTest.
Most of coding security is relating to this testing, such as handling exceptions and controlling how the code responds to invalid input.
It’s very context dependent,
On one end you might have an app that has a user base of 5 people, doesn’t use the Internet and doesn’t interact with other apps or files. On the other you might have an enterprise app that’s intended to be exposed on a public IP which accepts and processes public uploads.
As for working with security people, I used “mutual relationship of respect” because devs are ambivalent by nature but Sec is paranoid by nature. I find 99% of interactions tend be excellent and need to be handled first but security is a bottomless pursuit so if you suspect your project is being needlessly ground to a halt consult someone else in Sec to verify those things are reasonable for your apps exposure.
I’d agree though… those poll responses weren’t great lol. Just because you’re not a mechanic doesn’t mean you shouldn’t be interested in basic car maintenance, that kind of thing.
On picking a language it may be better to decide what you’d like to do first. If your code results in something exciting and useful you’d be surprised how “easy” it can become. C languages are a bit rough but the rest of the popular ones are varying degrees of not so bad.