Avoiding Security Risks for Developers
Software developers are not only responsible for writing codes, building, and testing applications. They must be responsible for avoiding security risks for the project and the company as a whole. Due to the growing use of the internet, applications, tools, and technology, security risks have skyrocketed. It’s a major challenge for any software developer to try to avoid the common threats that have dominated the software development industry for so long.
Avoiding Security Risks must be a part of the development strategy. I mean, I’ve seen a lot of companies first trying to build software, and later after it's ready for UAT, they try to find vulnerabilities and threats by hiring part-time pen testers and security engineers. The developers cannot keep up with fixing bugs, adding features, and doing RND to fix security bugs at that point in time. That would create havoc and be a pain for the organization. Hence, it should be a part of a day to day development life cycle. For example, it can be a part of the CI/CD pipeline.
There are many things that a software developer can do from their end to avoid security risks. A few of them are:
Keep Up With Dependencies
Dependencies are an indispensable part of any system. It is not possible to write everything from scratch and would not be better to re-invent the wheel when there are already a bunch of trusted dependencies/libraries being used by top-notch companies. Always while choosing a dependency/library, a software developer must check the community whether it is supported hitherto, the number of downloads, or companies that use it. In short, a developer must meticulously look into the details. Choosing dependency is one thing but keeping up with it is another. There can be a major bug in the previous versions that you are using and an exploiter can use it to exploit your system. It’s always advisable to check the release notes and keep up to date your dependencies and libraries.
We, software developers, and programmers are human beings though we don’t have a life. We, as human beings, find it so hard to manage secrets in our daily life. So is true in software development. There are many secrets that we use like passwords, tokens, keys etcetera. Usually, we, developers have to work under pressure and do everything in a rush. It can abstain us from managing secrets. The examples can be:
Posting a stack overflow question with code to resolve immediate bug which contains credentials
Committing and pushing official projects with credentials, keys, tokens in a public Github/Gitlab repo
Posting things online which contains sensitive information
It must be taken into consideration for maintaining the secrecy and avoiding the apocalypse.
Avoid Sharing Accounts
There is a common trend in a company to share the credentials of an account. Sharing a password is fine until it’s not. The more the credentials of an account are shared with individuals, the more the track of it is lost. Let’s say if the root account of AWS is shared among 20 developers and one of them deleted the EC2 instance then who is responsible for the havoc? How can we know what action is performed by which account because the account is shared?
The account can be created individually, if not possible, team-wise. It will minimize the risk because the account shared by 50 developers if hacked will impact more than the account shared by 4–5 developers. Also, if the account is used by more users, the more vulnerable it is and the tougher it is to manage secrecy.
The permissions to the systems, databases, tools, and technologies should be managed properly. It should be only provided to the ones that are accountable. The needed permissions should be granted not more than that. For instance, the client executive should not be provided access to the development environment. The application that needs to upload files to AWS S3 should only be provided access to that operation nothing more than that.
Remember database outrage in Gitlab? One engineer in Gitlab mistakenly deleted the primary production database instead of the secondary which resulted in the loss of 5000 projects, 5000 comments, and 700 new user accounts. One small mistake can result in a loss of reputation and a million dollars. If it can happen to a big company like Gitlab then is it inevitable for you?
Avoid Risky Behaviour
A skilled pilot with decades of experience can crash a plane when things go wrong. Similarly, skilled and trained developers can also create problems when their mental state is not good. Risky behaviors include:
Setting unrealistic deadlines
Working through fatigue
Taking shortcuts and cutting corners
Rushing through tasks to meet the deadlines and ignoring crucial aspects of the development
A short break or procrastination sometimes can be a good approach to avoiding risks.
Thanks a lot for reading this article. If you have anything in mind, then please feel free to comment or reach out to me. :)