CWE-1177 is what happens when a product uses a function, library or third party component that the developer or the customer has explicitly prohibited. The rule exists. The code ignores it.
It hits any team with a banned list, whether that list is a short file of C functions or a company policy about third party packages.
How it happens
MITRE gives several reasons someone might prohibit code: real or suspected vulnerabilities, difficulty using it securely, export controls or license requirements, obsolete or poorly maintained code, and internal code scheduled for deprecation. A developer may keep a list of banned functions that programmers must avoid because they are hard or impossible to use securely.
The weakness appears when that list is only a document. Nobody checks it, so a prohibited call slips in during a rushed change or arrives inside a new dependency.
MITRE's own examples are classic C. The first reads from standard input with gets(), which copies all input without checking size. The second copies with strcpy() into a fixed buffer without confirming the data fits.
/* Vulnerable pattern: both functions are on most banned lists */
char buf[24];
gets(buf); /* no size limit at all */
void manipulate_string(char *string) {
char buf[24];
strcpy(buf, string); /* no length check */
}
/* Fixed: bounded alternatives */
char buf[24];
if (fgets(buf, sizeof buf, stdin) == NULL) { /* handle EOF or error */ }
void manipulate_string(const char *string) {
char buf[24];
snprintf(buf, sizeof buf, "%s", string);
}
The record also lists two observed cases. CVE-2007-1470 is a library with multiple buffer overflows using sprintf() and strcpy(). CVE-2007-4004 is an FTP client that used the inherently insecure gets() function and was setuid root on some systems, allowing a buffer overflow.
What an attacker gains
Strictly, the consequence MITRE lists for this weakness is reduced maintainability. The security impact comes from what the prohibited code does. In the two examples above that is buffer overflow, because the banned functions cannot bound their writes.
How to find it
MITRE lists automated static analysis, often called SAST, as a detection method with high effectiveness. It analyzes source or compiled code by modeling data flow and control flow, then searching for patterns that connect sources of input to dangerous sinks.
A banned function list is the simplest rule a scanner can enforce. For components, you need an inventory to compare against policy. A software bill of materials lists what you ship so you can check it against what you prohibit.
How to fix it
MITRE's mitigation applies during build and implementation:
- Write down the list of prohibited API functions and give developers safer alternatives.
- Have code analysis tools or the compiler flag any use of a prohibited function. MITRE points to the
banned.hinclude file from Microsoft's SDL as one example. - Make the check part of the build so a violation fails the pull request.
- Apply the same idea to components. Keep a prohibited package list and check every dependency, including indirect ones, against it.
A list without enforcement is a suggestion.
Try it yourself
See what a dependency inventory looks like, then imagine checking it against your own prohibited list.
Click through it at your own pace, or open it full screen.
For your own project, the free in-browser dependency scan at gold.safeguard.sh/scan needs no login, keeps your file on your machine and handles up to 100 dependencies.
Quick check
Why is gets() on nearly every banned list?
It copies all input from standard input into a buffer with no size check, so a long enough string overflows the buffer.
Can a third party library be prohibited code?
Yes. MITRE says a function, library or third party component can be prohibited by the developer or the customer, for reasons that include vulnerabilities, licensing and obsolescence.
