How much does it cost to develop software? A lot is the generic reply, but in general, the costs vary depending on the complexity of the product created. At a salary of around $120K per year for a full-stack developer, your financial commitment is high when you develop source code. The price alone makes the software code you develop precious. But with intangibles such as the maintenance of your competitive edge, it becomes essential to protect your code. Your code, after all, is your secret sauce, the protection of such must be of the highest priority.
The theft of software code is not unusual. In a previous post about source code theft by developers, we talked about how common deliberate and accidental theft of source code is. If your source code ends up in a competitor’s hands it can have dire consequences.
There are, fortunately, a number of ways you can prevent your code from being stolen. Here, we help you to create a mental map of both legal and technological-based solutions to the ever-present problem of source code theft.
Ways and Means of Preventing Source Code Theft
Legal Structures
Putting legal and legislative structures in place creates a framework that builds a security ethos. This ethos is like a blanket that covers the entire way that your organization approaches source code creation. It instills a sense of corporate rather than individual ownership. In a culture where developers have a sense of owning the code they develop, it is vital to tease out the truth of ownership through legal frameworks.
Copyright:
We discussed the detail of the status of source code with respect to copyright law in a previous post. Source code can be copyrighted in a similar manner to literary works. Ownership though copyright, confers a number of basic rights fundamental to the sale and distribution of the resulting software. However, this mechanism alone is not enough to protect your source code from theft. Copyright is a nuanced form of protection that is linked directly to the produced code. It should be enforced by other frameworks such as your employment contract and legislation in your country around patent laws.
Patent and trade secret legislation:
The local laws of a country can have a serious impact on the effectiveness of a developer contract and copyright. It is important to take note of these and use legal advice to ensure you have robust protection.
The ENISA Threat Landscape Report 2018, offers an interesting note on how weak IP laws in certain countries can impact the safety of source code. The report gives an example saying that along with other countries, “…Russia demands source code reviews for all foreign technology being sold inside the country.” Opening your source code up like this, may need to be carefully considered.
Employment contracts:
The contract you establish with your software developer will set the foundation stone for ownership. If your organization can clearly set out ownership of the software developed, this can be a deterrent to source code theft. Employee contracts take a number of basic forms.
Direct employment contracts or “work-made-for-hire”: A company that employs a software developer to create code will own the copyright of that source code. If the employee wants to reuse that source code in personal projects or for any other third-party builds, they will have to license the source code. Where it can get complicated is if the developer creates code outside of the scope of the contract, for example, they may have their own personal Git repository where they create hobby projects.
Consultants and freelancers: Contracts with outsourced entities, either individuals or companies, need to be watertight. You would typically have in place:
- A Non-Disclosure Agreement – between the parties to protect your sensitive information and IP.
- Contract clauses that specifically tackle the ownership of source code and other related IP (such as architectural designs)
- If using an outsourcing firm, follow through by ensuring that the employees developing your code have the correct copyright clauses.
Technological Structures
Malicious and Accidental Insiders
Insider threats are a well-known source of general cybersecurity vulnerability. In a survey by BetterCloud they found that 91 percent of respondents felt vulnerable to this type of cybersecurity threat. The same survey found that 17 percent of companies were seriously concerned about the theft of intellectual property and trade secrets.
Carnegie Mellon University Software Engineering Institute, has detailed some of the types of issues that insider threats pose to source code. They include not only theft of source code but irreversible damage. The types of malicious acts showed examples of inserting malware into distributable code and code modification to allow movement of monies from financial accounts.
Malicious insiders are a known threat to our source code, and accidental insiders can also be a hazard. In a survey by Biscom, they found that 29 percent of employees had improperly shared source code and patent filings for software products. One of the most sensitive times in a developer’s work history, that results in source code theft, was when an employee left an organization. This was particularly an issue if they left under bad circumstances. In this case, 90 percent of employees said the main reason for theft of IP was because their employer did not have a policy or the technology to stop them from removing the IP.
Controlling the threats posed by insiders can be handled in a number of ways:
Data Loss Prevention (DLP): These tools are the foundation stone of any program of insider threat control. DLP is used to manage threats from both malicious and accidental insiders. The tools align with the lifecycle of data in your organization, namely data that is at rest, in transit, and in use. Software development is a process that involves all parts of the data lifecycle. DLP performs monitoring of data at a very deep level. Policies and rules are applied across the data (source code) lifecycle to contain its movement.
Behavioral monitoring: Suspicious behavior can be a dead giveaway for an insider threat. User Behavior Analytics tools (UBA) can be used to look for anomalous behavior that could be associated with malicious insiders. The tools work to collect data on endpoints such as workstations, and across networks and devices. Policies and rules are used to set alerts and build a profile of disallowed/suspicious actions.
Security Information and Event Management (SIEM): This is a management interface which collates and analyses log files output from network actions. The SIEM system will generate reports and alerts based on the data analysis.
Digital Forensics tools: Incidents need to be analyzed to help locate the source of a leak and to help determine how to plug any security gaps.
Security Awareness Training: Creating a culture of security is part of keeping data secure. If staff understand how risky behavior can become a security incident, they can mitigate accidental insider threats and prevent malicious ones.
The methods of insider threat control listed here can be used to form the basis for a program of insider threat management.
Outsider Threats
External threats to source code are another area that requires attention. The threat of an outsider is still the greatest source of data theft with around 75% of breaches involved external actors.
Outsider theft can be both malicious and occasionally accidental. Hacking groups such as the Indian group, Lords of Dharmaraja are known to target source code; Symantec’s code being an example of a victim of the group.
And even accidental outsiders can threaten source code and open up theft avenues. This was the case at Beta Archive who reportedly, accidentally posted Microsoft Windows 10 source code to their domain site.
In the previously mentioned report on the cybersecurity landscape by ENISA, they point out that care needs to be taken to manage “increasingly automated attacks through novel approaches to utilization of automated tools and skills.”
Having a robust program of cybersecurity threat mitigation is an essential foundation stone to protect Intellectual Property, including source code. Following advice such as the OWASP top ten security issue advisories and having a strategic security policy in place, is essential to stop source code leaks.
Creating a Mental Map of Source Code Protection Landscape
Building great source code is a team effort. It involves the coming together of a number of pieces of a puzzle that ends in your organization producing a great software product. Protecting that precious Intellectual Property is a given. But to do so effectively, you must have a mental map of the protection landscape. This includes understanding both the legal framework needed to protect source code, as well as the cyberthreats which exist.
This mental map forms the basis of an intelligent approach to putting in place the structures needed to make sure your source code stays safe.
Share: