Application security isn't enough. Though we design software to limit a malicious attack from hijacking processing logic or stealing data, a glaring omission exists: security against stealing the program source code itself. Few will discuss the problem. Fewer will admit to being victimized.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
"The physical security of source code does not get the attention it demands," said Michael Facemire, a Forrester Research vice president and principal analyst who serves application development and delivery professionals. "Protecting source code is no less important than protecting data."
In a 2014 white paper that examined the scourge of trade-secret theft, consultancy PwC said, "Cybercrime is not strictly speaking a technology problem. It is a strategy problem, a human problem and a process problem."
In other words, source code theft, a trade secret in the eyes of the law, has never been more alluring -- or easier. The bulky decks of Hollerith cards, rolls of punched paper tape or program printouts of greenbar paper -- tools of a bygone era -- aren't needed. For a developer jumping ship to the latest startup, or an operations staffer feeling underappreciated, a USB thumb drive, email attachment or surreptitious transmission via FTP will do just fine.
No one is immune from source code theft, not even the big guys. Source code for Adobe Acrobat was stolen in 2013, raising the specter of malware being embedded in PDF documents. Just a year earlier, Symantec -- itself a cybersecurity company -- had to deal with extortion attempts to keep the source code for Norton Antivirus private. In 2004, hackers set up shop to sell stolen source code for Cisco's PIX firewall. None of these thefts involved credit card numbers of other customer data.
The Goldman Sachs case
The magnitude of source code theft -- and the impotence of the legal system to deal with it adequately -- was highlighted with great alarm in the 72-page report, "Administration Strategy on Mitigating the Theft of U.S. Trade Secrets," published in February 2013 by the Executive Office of the President of the United States.
That report recounts a major software development project by Wall Street brokerage firm Goldman Sachs, which spent a half-billion dollars to develop a system to support high-frequency trading.
On his final day of employment in 2009 before jumping to a competitor, Goldman Sachs developer Sergey Aleynikov "transferred this extremely valuable proprietary computer code to an external computer server," along with thousands of other proprietary source code files to his home computers. Investigated by the FBI and prosecuted by the U.S. Attorney's Office of the Southern District of New York, he was convicted and sentenced to 97 months in federal prison.
In February 2012, the conviction was overturned. The problem: The theft was not of physical goods. In its opinion, the 2nd Circuit Court of Appeals wrote, "Because Aleynikov did not 'assume physical control' over anything when he took the source code, and because he did not thereby 'deprive [Goldman] of its use,' Aleynikov did not violate the [National Stolen Property Act]."
It wasn't until Dec. 28, 2012, that the loophole was closed when then-President Barack Obama signed Public Law 112-236, The Theft of Trade Secrets Clarification Act of 2012. As noted in the opinion, it was never Aleynikov's intention to impede Goldman Sachs from running the code.
A second conviction, in a New York state court, was tossed in 2015, because the trial judge believed the source code had to be printed on paper for a guilty finding. The conviction was reinstated in January 2017 by a unanimous vote of a New York state appeals court. "It would be incongruous to allow defendant to escape criminal liability merely because he made a digital copy of the misappropriated source code instead of printing it onto a piece of paper," wrote Justice Rosalyn Richter.
The federal report also identified numerous other cases of theft of trade secrets for the benefit of private companies and governmental organizations in China.
DevOps swims upstream
Dealing with potential source code theft needs to start long before a single line of code is ever written, according to Judith Hurwitz, a cloud consultant and CEO of Hurwitz & Associates in Needham, Mass. "If the first question is, 'What should an app do?' the second question must be, 'How do we keep the code, the processes and the data secure?'" she said.
One simple tactic -- watermarking source code with strings that can be searched for later -- doesn't prevent theft, but may facilitate the task of tracking down wayward code.
For WSM, a St. Clair Shores, Mich., consultancy that has been providing source code and to-the-cloud server migration services since 2003, the answer is a renewed emphasis on DevOps that gets the ops portion involved earlier in the dev process than stipulated by tradition.
"We're helping to consult on a 'left shift' in security, moving security practices further upstream into the development process to ensure that potential issues are caught before reaching production," said Jeremy Steinert, WSM's CTO. "This includes securing your code repository, continuous integration pipelines and development environments to ensure source code theft and security vulnerabilities are managed at every layer of the development process."
WSM has helped several companies recently with data-intrusion incidents intended to scrap customer data. "This isn't theft of code, but rather manipulation of it for the theft of customer data," Steinert said. The principles behind securing the codebase, repositories and processes around development are the same in both situations, he said.
WikiLeaks publishes code linked to CIA
Third-party software could pose source code vulnerability
Botnet source code leak begets offspring threats