The Bad Coding Habits That Leave Your Source Code Exposed

No one is perfect. Every developer, at some point will come across bad code. And at many points through their 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 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 into 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. This is why you need to use dependencies from trusted sources that are regularly maintained and reviewed for security issues.

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 which 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. 

Protect Your Source Code in Minutes

Learn how you can gain visibility into all of your organization’s
source code to protect it from theft and loss.

Related Posts

Life After A Source Code Leak

Life After A Source Code Leak

While many source code leaks are due to the nefarious deeds of hackers, the cause isn’t always a technical glitch. Some leaks are due to social engineering (cleverly deceiving an employee to share information), carelessness (an employee storing their work on personal devices), or worse, a disgruntled former employee stealing source code on their way out the door.

Read More »
Security Best Practices for Gitlab

Security Best Practices for Gitlab

Gitlab is an open-source power player in the SCM market, but when features sets expands, so do problems so it’s always better to review and update security settings to ensure your source code is secured using these best practices.

Read More »
Why Is Source Code So Hard To Protect?

Why Is Source Code So Hard To Protect?

Source code is the most valuable resource in your organization – it’s the company’s IP, the secret sauce. So why is securing source code so often neglected? Learn more about the vulnerabilities of the source code sprawl and how you can secure your source code.

Read More »