A look at how using a ‘Trust but Verify’ approach can be used to prevent your source code being stolen
If you type in the search term “Insider” “source code theft” you get over seven thousand search results returned. This reflects how major an issue source code theft is. Our software developers hold the jewels of our business in their hands. If they decide those jewels actually belong as much to themselves as they do to the business, then we are in trouble.
Within the list of returned results are a number of very interesting cases on insider threat and source code theft. The examples of source code theft include older as well as many recent and current examples. One such example is the case of code theft at Israeli mobile surveillance company, NGO Group. A senior software developer at NGO, allegedly, stole source code from the company and attempted to sell it on the dark web for $50 million USD. Cases like this are easy to find and are throwing up grave concerns for any company that creates software for internal or external use. (1)
To deal with a problem we need to understand why it happens. This article will explore the issue of just why developers want to steal source code?
The View of the Software Developer
People who become software developers are often extremely creative individuals. The creation of software is about making something. That something may be digital in form, but nevertheless, the process to build a software product is creative.
Creative people are generally passionate. They are dreamers and builders and their driver is to make something well. To become a software developer, especially a good one, you have to put the time in. Software developers have to not only learn their trade, but they have to keep up with a field that moves very quickly; new techniques, languages, and tools, pop up regularly in the field.
This passion for their craft and the inherent process in creating a product can result in a feeling of ownership of the code by the developer. Therein lies the fundamental issue behind code theft.
In a survey by the law publication Out-Law.com, they found that 80 percent of developers kept a personal library of their code and 85 percent took this code with them when they changed jobs. (2)
The View of the Company
Developers are not cheap. The average salary of a software developer is around $108,000 a year according to research by online recruiters, Indeed. Of course, there are also a variety of other costs associated with creating software: It all adds up to a large investment by your firm. (3)
And, if you pay for something you would rightly expect to own it.
Copyright law is there to protect an investment in creative work. We typically think of it as being applied to a book or an image. But it also applies to other creative works, like source code too. Copyright of source code is a way to protect your Intellectual Property (IP). Many countries have different interpretations of copyright law. However, the fundamental tenet is that you use a contract with a copyright clause to prevent unauthorized copying of the software you have paid for. In a pivotal case in the USA, the copyright of source code was established. This case, heard in 1983, was Apple vs. Franklin, and it set a precedent that source code was equivalent to a “literary work”. (4)
Of course, in the day-to-day world of running a business, things are more complicated than this. Software often utilizes other code, such as libraries and open source. But licensing takes care of this. The problem of source code theft is about the reuse of large portions of code that is specifically used to create a product your company uses or sells. And, it can also be about the exposure of your company source code to competitors.
How to foster an environment where your developers respect the right to ownership by your firm of the code they create, is a challenge. We will look at how to overcome this challenge later in this piece using a ‘Trust but Verify’ approach.
Insider Theft, Software Developers, and Source Code
Before looking at ways to mitigate source code theft, let’s take a look at the problem of source code theft/loss in some more detail. When, how, and why do developers steal code? This can be answered by breaking the problem down into specific areas of concern.
Accidental Code Exposure
Software developers are part of a wider community. Like any profession, they like to discuss ideas, issues, and best practice with peers. Online portals like Stack Overflow, Code Project and a variety of subReddits, allow programmers to discuss and share their work. It is somewhat natural, if you are proud of something, to want to ‘show it off’. It is this behavior that can end in non-malicious source code exposure. (5,6)
If you put in the search term “code sample” into the Stack Overflow search tool, you will find countless examples of source code. Many of these samples will be the Intellectual property (IP) of a firm. These samples are shared, and even re-shared from other sources, possibly with competitors. This sharing, in the name of collaboration and community support, effectively exposes company IP. It is in no way malicious, and it may indeed help your own developers to resolve complex issues. Nonetheless, it is exposure of proprietary data.
Non-Accidental Source Code Theft
The IP Commission Report for 2017, found that in the U.S. losses due to the theft of trade secrets ran to between 1% and 3% of GDP. This equates to financial losses of between $180 billion and $540 billion. This situation is reflected globally. McAfee estimates global costs of IP theft, for which source code exposure is a contributing factor, at 0.8% of global GDPR. (7,8)
Exposure of copyrighted source code does not have to be malicious to be detrimental to your organization. As mentioned earlier. The very act of developing source code can imbue a developer with a sense of ownership. Even if the developer is paid well for the development, it is often hard to separate a developer from their code. Programmers commonly reuse code. This is exemplified by the wide use of community support platforms like the earlier mentioned Stack Overflow.
Transient Developers and Source Code Loss
The problem of source code ownership and reuse is exacerbated when the programmer is a freelancer or leaves your organization. The ‘loose coupling’ of a developer to a company has intrinsic issues around loyalty and can exacerbate the threat of the insider.
Insider threats are a serious concern when putting in place protection against source code theft. The point at which an individual gives notice is the most likely time that IP theft occurs. An example of this was the case of Goldman Sachs and developer, Sergey Aleynikov. Goldman Sachs invested millions developing a high frequency trading program. Mr. Aleynikov transferred the underlying source code to an external server, on his resignation to work for a competitor. Mr. Aleynikov was prosecuted by the U.S. Attorney’s Office and sentenced to 97 months in prison. The conviction was subsequently overturned on appeal because of a loophole; this was later closed off by updated legislation. (9)
Developer allegiance with your organization is an important aspect of preventing source code theft. Developers who are consultants, freelancers, off-site or about to leave, may not have a strong enough connection with your company to prevent them from walking away with your source code. This is where a technological solution that provides source code theft prevention can offer a way to mitigate insider threats.
How to Stop Source Code Leaks – Trust but Verify – Baking in Verification
The problem of source code theft comes down to the ease of which it can happen. Preventing source code theft is a problem of massive consequence and so must be given due thought.
Modern business practices are built upon the ideal of trusted relationships between employer and employed. The problem occurs when insiders, who should be part of this trusted relationship, become the perpetrators of the threat. Insider threat is a major cause of data theft. According to McAfee, 43% of data loss is initiated by an insider. In another report on insider threats, Computer Associates (CA) found that more than half of insider threats came from IT and privileged employees. (10,11)
The idea of “Trust but Verify” has roots in the development of a bilateral trusted relationship. Modern management places emphasis on trusting and empowering employees. This is a good goal to aim for. However, the consequences of IP theft, including source code loss, is massive. Not only financial loss but reputation damage, lost work time and attorney fees, trying to fix the results of the theft.
Trust is not a one-way street. Trust is something that is built up, over time, and with direct feedback. Verification of employees should neither be seen as a failing on the business part nor as disrespectful to the employee. Instead, it should be seen as a normal company process to protect everyone.
Some ways to help create this trusted relationship, that has verification baked in, include using a combination of both social and technological approaches:
- Great employee communications. Having a culture of communication where employees are listened to can help in building mutual respect. This, in turn, fosters a feeling of connection with the organization and builds trust.
- Have clear policies and contracts. Your organization should set out clear policies around the ownership of source code. This should extend to ensuring that developer contracts, expressly set out the ownership of source code. Clear limits of its use, including exposure on public platforms, should be included.
- Data loss prevention tools and methodologies. Even with a trusted relationship, accidents happen. A source code theft protection solution can monitor source code files and associated applications and prevent accidental or malicious source code exposure.
Returning to the Out-Law.com survey, after reviewing the results, they suggest that to prevent IP theft in the form of source code exposure:
“The key message for any company is that it should have an audit trail for its software development projects,”
Good business practice begins when you use the best methods and tools at your disposal. Trusting your employees, especially highly intelligent and creative ones, must be based on mutual respect. But trust must be shored up by practical methods which use source code theft prevention tools. Together, this social plus technological approach can ensure your organization does not end up at a loss because of source code theft.
- Apple Insider: https://appleinsider.com/articles/18/07/06/nso-group-employee-allegedly-stole-attempted-to-sell-pegasus-ios-malware-for-50m
- Out-Law.com: https://www.out-law.com/page-4613
- Indeed: https://www.indeed.com/salaries/Software-Engineer-Salaries
- Open Jurist, Apple Computer Inc v. Franklin Computer Corporation: https://openjurist.org/714/f2d/1240/apple-computer-inc-v-franklin-computer-corporation
- Stack Overflow: https://stackoverflow.com/
- Code Project: https://www.codeproject.com/
- IP Commission Report 2017: http://www.ipcommission.org/report/IP_Commission_Report_Update_2017.pdf
- McAfee: https://www.mcafee.com/enterprise/en-us/assets/executive-summaries/es-economic-impact-cybercrime.pdf
- Justice,gov: https://www.justice.gov/criminal-ccips/file/938321/download
- McAfee: https://www.mcafee.com/enterprise/en-us/assets/reports/rp-data-exfiltration.pdf
- Computer Associates: https://www.ca.com/us/products/insider-threat.html