No one is perfect. Every developer, at some point, will come across bad code. Bad coding habits come easy, and these bad habits stick without guidance from a senior engineer. At many points through an engineer’s own development of their coding skills, they will be the guilty party responsible for writing bad code. That’s how you learn and get better, right?
But what happens when developers who lack experience or skills are the ones with access to the organization’s intellectual property that is your source code?
That’s right. Your source code is now in the danger zone.
The problem is, not every company has the resources to only hire top talent. And even if they did, new generations of developers will always be coming in. There is no escaping the mistakes of the less experienced, but there are checklists to put into place for devs to look out for to try and alleviate the worst-case coding scenarios.
The Top 5 Absolute Worst Bad Coding Habits
In our experience, these are the worst coding habits that leave your source code exposed:
Copy / pasting code without checking it.
Say what!? Always, always review your code before you copy and paste it. And again after you paste it. A single typo can create chaos in your code. If you work on autopilot or get lazy and don’t double-check yourself, you will wreck yourself, and the code and expose the source code.
Using bad code can also introduce vulnerabilities to your code base. If the source code you are copying has vulnerabilities in it, you copy them as well.
And another thing – one never knows the ‘intent’ of the code.If you copy a large amount of code without checking it, it might have some hidden malicious sections that won’t stand out at first glance.
Always review your code for the unexpected, small errors.
Using unvetted libraries and dependencies.
A trend we have seen over the last few years is the hijacking of libraries, or the take over of libraries that have not been maintained. Security vulnerabilities are not likely to be fixed and using it exposes source code to those vulnerabilities as well. This is why you need to use dependencies from trusted sources that are regularly maintained and reviewed for security issues.
Loose permission model.
Would you travel in a car with loose wheel bolts? Or skydive without a parachute? No. So why take a chance with your organization’s most precious resource, the IP?
Make sure to remove all unnecessary access – that means checking that former employees and consultants have access removed, if teams move off of one project and onto a new one, revoke. Anyone who doesn’t need access shouldn’t have it. Make this a monthly habit and it won’t build up.
Keeping secrets in code.
What is a secret? It’s something that is meant to be kept unknown or unseen by others. So why would you put a secret in a publicly accessible (by external or too many internal users) chunk of code? Where it will most likely be exposed? Why?
Handle your source code with care. Put it into a configuration file that is read by your code at startup. Configuration files shouldn’t be put on version control unless they are the “factory defaults”, and then they shouldn’t have any private information. Use features such as .gitignore, or user environment variables to make sure these are ignored by your source code and won’t find their way to your online repositories.
Ignoring proven best practices
Best practices, such as performing code reviews and writing tests are carefully honed tactics that have been tested over and over again and provide the best security methods for securing your source code. Don’t ignore them.
Source code is very hard to protect but it is more than possible.
Cycode’s source code control, detection, and response solution, ensures that source code repositories are always monitored with mechanisms in place to provide an immediate alert and response to protect your source code anytime an attempted breach is detected.
