DeepSeek is unsafe for enterprise use, tests reveal

The birth of China’s DeepSeek AI technology clearly sent shockwaves throughout the industry, with many lauding it as a faster, smarter and cheaper alternative to well-established LLMs.

However, similar to the hype train we saw (and continue to see) for the likes of OpenAI and ChatGPT’s current and future capabilities, the reality of its prowess lies somewhere between the dazzling controlled demonstrations and significant dysfunction, especially from a security perspective.

Recent research by AppSOC revealed critical failures in multiple areas, including susceptibility to jailbreaking, prompt injection, and other security toxicity, with researchers particularly disturbed by the ease with which malware and viruses can be created using the tool. This renders it too risky for business and enterprise use, but that is not going to stop it from being rolled out, often without the knowledge or approval of enterprise security leadership.

With approximately 76% of developers using or planning to use AI tooling in the software development process, the well-documented security risks of many AI models should be a high priority to actively mitigate against, and DeepSeek’s high accessibility and rapid adoption positions it a challenging potential threat vector. However, the right safeguards and guidelines can take the security sting out of its tail, long-term.

DeepSeek: The Ideal Pair Programming Partner?

One of the first impressive use cases for DeepSeek was its ability to produce quality, functional code to a standard deemed better than other open-source LLMs via its proprietary DeepSeek Coder tool. Data from DeepSeek Coder’s GitHub page states:

“We evaluate DeepSeek Coder on various coding-related benchmarks. The result shows that DeepSeek-Coder-Base-33B significantly outperforms existing open-source code LLMs.”

The extensive test results on the page offer tangible evidence that DeepSeek Coder is a solid option against competitor LLMs, but how does it perform in a real development environment? ZDNet’s David Gewirtz ran several coding tests with DeepSeek V3 and R1, with decidedly mixed results, including outright failures and verbose code output. While there is a promising trajectory, it would appear to be quite far from the seamless experience offered in many curated demonstrations.

And we have barely touched on secure coding, as yet. Cybersecurity firms have already uncovered that the technology has backdoors that send user information directly to servers owned by the Chinese government, indicating that it is a significant risk to national security. In addition to a penchant for creating malware and weakness in the face of jailbreaking attempts, DeepSeek is said to contain outmoded cryptography, leaving it vulnerable to sensitive data exposure and SQL injection.

Perhaps we can assume these elements will improve in subsequent updates, but independent benchmarking from Baxbench, plus a recent research collaboration between academics in China, Australia and New Zealand reveal that, in general, AI coding assistants produce insecure code, with Baxbench in particular indicating that no current LLM is ready for code automation from a security perspective. In any case, it will take security-adept developers to detect the issues in the first place, not to mention mitigate them.

The issue is, developers will choose whatever AI model will do the job fastest and cheapest. DeepSeek is functional, and above all, free, for quite powerful features and capabilities. I know many developers are already using it, and in the absence of regulation or individual security policies banning the installation of the tool, many more will adopt it, the end result being that potential backdoors or vulnerabilities will make their way into enterprise codebases.

It cannot be overstated that security-skilled developers leveraging AI will benefit from supercharged productivity, producing good code at a greater pace and volume. Low-skilled developers, however, will achieve the same high levels of productivity and volume, but will be filling repositories with poor, likely exploitable code. Enterprises that do not effectively manage developer risk will be among the first to suffer.

Shadow AI remains a significant expander of the enterprise attack surface

CISOs are burdened with sprawling, overbearing tech stacks that create even more complexity in an already complicated enterprise environment. Adding to that burden is the potential for risky, out-of-policy tools being introduced by individuals who don’t understand the security impact of their actions.

Wide, uncontrolled adoption – or worse, covert “shadow” use in development teams despite restrictions – is a recipe for disaster. CISOs need to implement business-appropriate AI guardrails and approved tools despite weakening or unclear legislation, or face the consequences of rapid-fire poison into their repositories.

In addition, modern security programs must make developer-driven security a key driving force of risk and vulnerability reduction, and that means investing in their ongoing security upskilling as it relates to their role.

Conclusion

The AI space is evolving, seemingly at the speed of light, and while these advancements are undoubtedly exciting, we as security professionals cannot lose sight of the risk involved in their implementation at the enterprise level. DeepSeek is taking off across the world, but for most use cases, it carries unacceptable cyber risk.

Security leaders should consider the following:

• Stringent internal AI policies: Banning AI tools altogether is not the solution, as many
  developers will find a way around any restrictions and continue to compromise the
  company. Investigate, test, and approve a small suite of AI tooling that can be safely
  deployed according to established AI policies. Allow developers with proven security
  skills to use AI on specific code repositories, and disallow those who have not been
  verified.
• Custom security learning pathways for developers: Software development is
  changing, and developers need to know how to navigate vulnerabilities in the languages
  and frameworks they actively use, as well as apply working security knowledge to third-
  party code, whether it is an external library or generated by an AI coding assistant. If
  multi-faceted developer risk management, including continuous learning, is not part of
  the enterprise security program, it falls behind.
• Get serious about threat modeling: Most enterprises are still not implementing threat
  modeling in a seamless, functional way, and they especially do not involve developers.
  This is a great opportunity to pair security-skilled developers (after all, they know their
  code best) with their AppSec counterparts for enhanced threat modeling exercises, and
  analyzing new AI threat vectors.