1FLAWFINDER(1) Flawfinder FLAWFINDER(1)
2
6 flawfinder - find potential security flaws ("hits") in source code
7
9 flawfinder [--help] [--version] [--allowlink] [--inputs|-I] [ --min‐
10 level X | -m X ] [--falsepositive|-F] [--neverignore|-n] [--patch file‐
11 name|-P filename] [--followdotdir] [--context|-c] [--columns|-C]
12 [--dataonly|-D] [--html] [--immediate|-i] [--singleline|-S] [--omit‐
13 time] [--quiet|-Q] [ --loadhitlist F ] [ --savehitlist F ] [
14 --diffhitlist F ] [--] [ source code file or source root directory ]+
15
17 Flawfinder searches through C/C++ source code looking for potential
18 security flaws. To run flawfinder, simply give flawfinder a list of
19 directories or files. For each directory given, all files that have
20 C/C++ filename extensions in that directory (and its subdirectories,
21 recursively) will be examined. Thus, for most projects, simply give
22 flawfinder the name of the source code's topmost directory (use ``.''
23 for the current directory), and flawfinder will examine all of the
24 project's C/C++ source code. If you only want to have changes
25 reviewed, save a unified diff of those changes (created by "diff -u" or
26 "svn diff") in a patch file and use the --patch (-P) option.
27 Flawfinder will produce a list of ``hits'' (potential security flaws),
29 sorted by risk; the riskiest hits are shown first. The risk level is
30 shown inside square brackets and varies from 0, very little risk, to 5,
31 great risk. This risk level depends not only on the function, but on
32 the values of the parameters of the function. For example, constant
33 strings are often less risky than fully variable strings in many con‐
34 texts, and in those contexts the hit will have a lower risk level.
35 Flawfinder knows about gettext (a common library for internationalized
36 programs) and will treat constant strings passed through gettext as
37 though they were constant strings; this reduces the number of false
38 hits in internationalized programs. Flawfinder will do the same sort
39 of thing with _T() and _TEXT(), common Microsoft macros for handling
40 internationalized programs Flawfinder correctly ignores most text
41 inside comments and strings. Normally flawfinder shows all hits with a
42 risk level of at least 1, but you can use the --minlevel option to show
43 only hits with higher risk levels if you wish.
44 Not every hit is actually a security vulnerability, and not every secu‐
46 rity vulnerability is necessarily found. Nevertheless, flawfinder can
47 be an aid in finding and removing security vulnerabilities. A common
48 way to use flawfinder is to first apply flawfinder to a set of source
49 code and examine the highest-risk items. Then, use --inputs to examine
50 the input locations, and check to make sure that only legal and safe
51 input values are accepted from untrusted users.
52 Once you've audited a program, you can mark source code lines that are
54 actually fine but cause spurious warnings so that flawfinder will stop
55 complaining about them. To mark a line so that these warnings are sup‐
56 pressed, put a specially-formatted comment either on the same line
57 (after the source code) or all by itself in the previous line. The
58 comment must have one of the two following formats:
59 ·
61 // Flawfinder: ignore
62 ·
64 /* Flawfinder: ignore */
65 Note that, for compatibility's sake, you can replace "Flawfinder:" with
67 "ITS4:" or "RATS:" in these specially-formatted comments. Since it's
68 possible that such lines are wrong, you can use the ``--neverignore''
69 option, which causes flawfinder to never ignore any line no matter what
70 the comments say. Thus, responses that would otherwise be ignored
71 would be included (or, more confusingly, --neverignore ignores the
72 ignores). This comment syntax is actually a more general syntax for
73 special directives to flawfinder, but currently only ignoring lines is
74 supported.
75 Flawfinder uses an internal database called the ``ruleset''; the rule‐
77 set identifies functions that are common causes of security flaws. The
78 standard ruleset includes a large number of different potential prob‐
79 lems, including both general issues that can impact any C/C++ program,
80 as well as a number of specific Unix-like and Windows functions that
81 are especially problematic. As noted above, every potential security
82 flaw found in a given source code file (matching an entry in the rule‐
83 set) is called a ``hit,'' and the set of hits found during any particu‐
84 lar run of the program is called the ``hitlist.'' Hitlists can be
85 saved (using --savehitlist), reloaded back for redisplay (using --load‐
86 hitlist), and you can show only the hits that are different from
87 another run (using --diffhitlist).
88 Any filename given on the command line will be examined (even if it
90 doesn't have a usual C/C++ filename extension); thus you can force
91 flawfinder to examine any specific files you desire. While searching
92 directories recursively, flawfinder only opens and examines regular
93 files that have C/C++ filename extensions. Flawfinder presumes that,
94 files are C/C++ files if they have the extensions ".c", ".h", ".ec",
95 ".ecp", ".pgc", ".C", ".cpp", ".CPP", ".cxx", ".cc", ".CC", ".pcc",
96 ".hpp", or ".H". The filename ``-'' means the standard input. To pre‐
97 vent security problems, special files (such as device special files and
98 named pipes) are always skipped, and by default symbolic links are
99 skipped,
100 After the list of hits is a brief summary of the results (use -D to
102 remove this information). It will show the number of hits, lines ana‐
103 lyzed (as reported by wc -l), and the physical source lines of code
104 (SLOC) analyzed. A physical SLOC is a non-blank, non-comment line. It
105 will then show the number of hits at each level; note that there will
106 never be a hit at a level lower than minlevel (1 by default). Thus,
107 "[0] 0 [1] 9" means that at level 0 there were 0 hits reported, and
108 at level 1 there were 9 hits reported. It will next show the number of
109 hits at a given level or larger (so level 3+ has the sum of the number
110 of hits at level 3, 4, and 5). Thus, an entry of "[0+] 37" shows that
111 at level 0 or higher there were 37 hits (the 0+ entry will always be
112 the same as the "hits" number above). Hits per KSLOC is next shown;
113 this is each of the "level or higher" values multiplied by 1000 and
114 divided by the physical SLOC. If symlinks were skipped, the count of
115 those is reported. If hits were suppressed (using the "ignore" direc‐
116 tive in source code comments as described above), the number suppressed
117 is reported. The minimum risk level to be included in the report is
118 displayed; by default this is 1 (use --minlevel to change this). The
119 summary ends with important reminders: Not every hit is necessarily a
120 security vulnerability, and there may be other security vulnerabilities
121 not reported by the tool.
122 Flawfinder intentionally works similarly to another program, ITS4,
124 which is not fully open source software (as defined in the Open Source
125 Definition) nor free software (as defined by the Free Software Founda‐
126 tion). The author of Flawfinder has never seen ITS4's source code.
127
129 Here's a brief example of how flawfinder might be used. Imagine that
130 you have the C/C++ source code for some program named xyzzy (which you
131 may or may not have written), and you're searching for security vulner‐
132 abilities (so you can fix them before customers encounter the vulnera‐
133 bilities). For this tutorial, I'll assume that you're using a Unix-
134 like system, such as Linux, OpenBSD, or MacOS X.
135 If the source code is in a subdirectory named xyzzy, you would probably
138 start by opening a text window and using flawfinder's default settings,
139 to analyze the program and report a prioritized list of potential secu‐
140 rity vulnerabilities (the ``less'' just makes sure the results stay on
141 the screen):
142 flawfinder xyzzy | less
143 At this point, you will a large number of entries; each entry begins
146 with a filename, a colon, a line number, a risk level in brackets
147 (where 5 is the most risky), a category, the name of the function, and
148 a description of why flawfinder thinks the line is a vulnerability.
149 Flawfinder normally sorts by risk level, showing the riskiest items
150 first; if you have limited time, it's probably best to start working on
151 the riskiest items and continue until you run out of time. If you want
152 to limit the display to risks with only a certain risk level or higher,
153 use the --minlevel option. If you're getting an extraordinary number
154 of false positives because variable names look like dangerous function
155 names, use the -F option to remove reports about them. If you don't
156 understand the error message, please see documents such as the Writing
157 Secure Programs for Linux and Unix HOWTO
158 ⟨http://www.dwheeler.com/secure-programs⟩ at
159 http://www.dwheeler.com/secure-programs which provides more information
160 on writing secure programs.
161 Once you identify the problem and understand it, you can fix it. Occa‐
164 sionally you may want to re-do the analysis, both because the line num‐
165 bers will change and to make sure that the new code doesn't introduce
166 yet a different vulnerability.
167 If you've determined that some line isn't really a problem, and you're
170 sure of it, you can insert just before or on the offending line a com‐
171 ment like
172 /* Flawfinder: ignore */
173 to keep them from showing up in the output.
174 Once you've done that, you should go back and search for the program's
177 inputs, to make sure that the program strongly filters any of its
178 untrusted inputs. Flawfinder can identify many program inputs by using
179 the --inputs option, like this:
180 flawfinder --inputs xyzzy
181 Flawfinder can integrate well with text editors and integrated develop‐
184 ment environments; see the examples for more information.
185 Flawfinder includes many other options, including ones to create HTML
188 versions of the output (useful for prettier displays). The next sec‐
189 tion describes those options in more detail.
190
193 Flawfinder has a number of options, which can be grouped into options
194 that control its own documentation, select which hits to display,
195 select the output format, and perform hitlist management.
196 Documentation
199 --help Show usage (help) information.
200 --version Shows (just) the version number and exits.
203 Selecting Hits to Display
206 --patchpatchfile
207 -Ppatchfile Only report hits that are changed by the given
208 patch file. The patch file must be in unified diff format
209 (e.g., the output of "diff -u old new" or "svn diff"),
210 where the new files are the ones that are being examined by
211 flawfinder. The line numbers given in the patch file are
212 used to determine which lines were changed, so if you have
213 modified the files since the patch file was created, regen‐
214 erate the patch file first. Beware that the file names of
215 the new files given in the patch file must match exactly,
216 including upper/lower case, path prefix, and directory sep‐
217 arator (\ vs. /). Only unified diff format is accepted
218 (either GNU diff or svn diff output is okay); if you have a
219 different format, again regenerate it first. Only hits
220 that occur on resultant changed lines, or immediately above
221 and below them, are reported. This option implies --nev‐
222 erignore.
223 --allowlink Allow the use of symbolic links; normally symbolic links
226 are skipped. Don't use this option if you're analyzing
227 code by others; attackers could do many things to cause
228 problems for an analysis with this option enabled. For
229 example, an attacker could insert symbolic links to files
230 such as /etc/passwd (leaking information about the file) or
231 create a circular loop, which would cause flawfinder to run
232 ``forever''. Another problem with enabling this option is
233 that if the same file is referenced multiple times using
234 symbolic links, it will be analyzed multiple times (and
235 thus reported multiple times). Note that flawfinder
236 already includes some protection against symbolic links to
237 special file types such as device file types (e.g.,
238 /dev/zero or C:\mystuff\com1). Note that for flawfinder
239 version 1.01 and before, this was the default.
240 --inputs
243 -I Show only functions that obtain data from outside the pro‐
245 gram; this also sets minlevel to 0.
246 --minlevel=X
249 -m X Set minimum risk level to X for inclusion in hitlist. This
251 can be from 0 (``no risk'') to 5 (``maximum risk''); the
252 default is 1.
253 --falsepositive
256 -F Do not include hits that are likely to be false positives.
258 Currently, this means that function names are ignored if
259 they're not followed by "(", and that declarations of char‐
260 acter arrays aren't noted. Thus, if you have use a vari‐
261 able named "access" everywhere, this will eliminate refer‐
262 ences to this ordinary variable. This isn't the default,
263 because this also increases the likelihood of missing
264 important hits; in particular, function names in #define
265 clauses and calls through function pointers will be missed.
266 --neverignore
269 -n Never ignore security issues, even if they have an
271 ``ignore'' directive in a comment.
272 --followdotdir
275 Enter directories whose names begin with ".". Normally
276 such directories are ignored, since they normally include
277 version control private data, configurations, and so on.
278 Selecting Output Format
281 --columns
282 -C Show the column number (as well as the file name and line
284 number) of each hit; this is shown after the line number by
285 adding a colon and the column number in the line (the first
286 character in a line is column number 1). This is useful
287 for editors that can jump to specific columns, or for inte‐
288 grating with other tools (such as those to further filter
289 out false positives).
290 --context
293 -c Show context, i.e., the line having the "hit"/potential
295 flaw. By default the line is shown immediately after the
296 warning.
297 --dataonly
300 -D Don't display the header and footer. Use this along with
302 --quiet to see just the data itself.
303 --html Format the output as HTML instead of as simple text.
306 --immediate
309 -i Immediately display hits (don't just wait until the end).
311 --singleline
314 -S Display as single line of text output for each hit. Useful
316 for interacting with compilation tools.
317 --omittime Omit timing information. This is useful for regression
320 tests of flawfinder itself, so that the output doesn't vary
321 depending on how long the analysis takes.
322 --quiet
325 -Q Don't display status information (i.e., which files are
327 being examined) while the analysis is going on.
328 Hitlist Management
332 --savehitlist=F
333 Save all resulting hits (the "hitlist") to F.
334 --loadhitlist=F
337 Load the hitlist from F instead of analyzing source pro‐
338 grams.
339 --diffhitlist=F
342 Show only hits (loaded or analyzed) not in F. F was pre‐
343 sumably created previously using --savehitlist. If the
344 --loadhitlist option is not provided, this will show the
345 hits in the analyzed source code files that were not previ‐
346 ously stored in F. If used along with --loadhitlist, this
347 will show the hits in the loaded hitlist not in F. The
348 difference algorithm is conservative; hits are only consid‐
349 ered the ``same'' if they have the same filename, line num‐
350 ber, column position, function name, and risk level.
351
355 Here are various examples of how to invoke flawfinder. The first exam‐
356 ples show various simple command-line options. Flawfinder is designed
357 to work well with text editors and integrated development environments,
358 so the next sections show how to integrate flawfinder into vim and
359 emacs.
360 Simple command-line options
363 flawfinder /usr/src/linux-2.4.12
364 Examine all the C/C++ files in the directory
365 /usr/src/linux-2.4.12 and all its subdirectories (recur‐
366 sively), reporting on all hits found.
367 flawfinder --minlevel=4 .
370 Examine all the C/C++ files in the current directory and
371 its subdirectories (recursively); only report vulnerabili‐
372 ties level 4 and up (the two highest risk levels).
373 flawfinder --inputs mydir
376 Examine all the C/C++ files in mydir and its subdirectories
377 (recursively), and report functions that take inputs (so
378 that you can ensure that they filter the inputs appropri‐
379 ately).
380 flawfinder --neverignore mydir
383 Examine all the C/C++ files in the directory mydir and its
384 subdirectories, including even the hits marked for ignoring
385 in the code comments.
386 flawfinder -QD mydir
389 Examine mydir and report only the actual results (removing
390 the header and footer of the output). This form is useful
391 if the output will be piped into other tools for further
392 analysis. The -C (--columns) and -S (--singleline) options
393 can also be useful if you're piping the data into other
394 tools.
395 flawfinder --quiet --html --context mydir > results.html
398 Examine all the C/C++ files in the directory mydir and its
399 subdirectories, and produce an HTML formatted version of
400 the results. Source code management systems (such as
401 SourceForge and Savannah) might use a command like this.
402 flawfinder --quiet --savehitlist saved.hits *.[ch]
405 Examine all .c and .h files in the current directory.
406 Don't report on the status of processing, and save the
407 resulting hitlist (the set of all hits) in the file
408 saved.hits.
409 flawfinder --diffhitlist saved.hits *.[ch]
412 Examine all .c and .h files in the current directory, and
413 show any hits that weren't already in the file saved.hits.
414 This can be used to show only the ``new'' vulnerabilities
415 in a modified program, if saved.hits was created from the
416 older version of the program being analyzed.
417 Invoking from vim
420 The text editor vim includes a "quickfix" mechanism that works well
421 with flawfinder, so that you can easily view the warning messages and
422 jump to the relevant source code.
423 First, you need to invoke flawfinder to create a list of hits, and
425 there are two ways to do this. The first way is to start flawfinder
426 first, and then (using its output) invoke vim. The second way is to
427 start (or continue to run) vim, and then invoke flawfinder (typically
428 from inside vim).
429 For the first way, run flawfinder and store its output in some FLAWFILE
431 (say "flawfile"), then invoke vim using its -q option, like this: "vim
432 -q flawfile". The second way (starting flawfinder after starting vim)
433 can be done a legion of ways. One is to invoke flawfinder using a
434 shell command, ":!flawfinder-command > FLAWFILE", then follow that with
435 the command ":cf FLAWFILE". Another way is to store the flawfinder
436 command in your makefile (as, say, a pseudocommand like "flaw"), and
437 then run ":make flaw".
438 In all these cases you need a command for flawfinder to run. A plausi‐
440 ble command, which places each hit in its own line (-S) and removes
441 headers and footers that would confuse it, is:
442 flawfinder -SQD .
444 You can now use various editing commands to view the results. The com‐
447 mand ":cn" displays the next hit; ":cN" displays the previous hit, and
448 ":cr" rewinds back to the first hit. ":copen" will open a window to
449 show the current list of hits, called the "quickfix window"; ":cclose"
450 will close the quickfix window. If the buffer in the used window has
451 changed, and the error is in another file, jumping to the error will
452 fail. You have to make sure the window contains a buffer which can be
453 abandoned before trying to jump to a new file, say by saving the file;
454 this prevents accidental data loss.
455 Invoking from emacs
458 The text editor / operating system emacs includes "grep mode" and "com‐
459 pile mode" mechanisms that work well with flawfinder, making it easy to
460 view warning messages, jump to the relevant source code, and fix any
461 problems you find.
462 First, you need to invoke flawfinder to create a list of warning mes‐
464 sages. You can use "grep mode" or "compile mode" to create this list.
465 Often "grep mode" is more convenient; it leaves compile mode untouched
466 so you can easily recompile once you've changed something. However, if
467 you want to jump to the exact column position of a hit, compile mode
468 may be more convenient because emacs can use the column output of
469 flawfinder to directly jump to the right location without any special
470 configuration.
471 To use grep mode, enter the command "M-x grep" and then enter the
473 needed flawfinder command. To use compile mode, enter the command "M-x
474 compile" and enter the needed flawfinder command. This is a meta-key
475 command, so you'll need to use the meta key for your keyboard (this is
476 usually the ESC key). As with all emacs commands, you'll need to press
477 RETURN after typing "grep" or "compile". So on many systems, the grep
478 mode is invoked by typing ESC x g r e p RETURN.
479 You then need to enter a command, removing whatever was there before if
481 necessary. A plausible command is:
482 flawfinder -SQDC .
484 This command makes every hit report a single line, which is much easier
486 for tools to handle. The quiet and dataonly options remove the other
487 status information not needed for use inside emacs. The trailing
488 period means that the current directory and all descendents are
489 searched for C/C++ code, and analyzed for flaws.
490 Once you've invoked flawfinder, you can use emacs to jump around in its
492 results. The command C-x ` (Control-x backtick) visits the source code
493 location for the next warning message. C-u C-x ` (control-u control-x
494 backtick) restarts from the beginning. You can visit the source for
495 any particular error message by moving to that hit message in the *com‐
496 pilation* buffer or *grep* buffer and typing the return key. (Techni‐
497 cal note: in the compilation buffer, this invokes compile-goto-error).
498 You can also click the Mouse-2 button on the error message (when using
499 the mouse you don't need to switch to the *compilation* buffer first).
500 If you want to use grep mode to jump to specific columns of a hit,
502 you'll need to specially configure emacs to do this. To do this, mod‐
503 ify the emacs variable "grep-regexp-alist". This variable tells Emacs
504 how to parse output of a "grep" command, similar to the variable "com‐
505 pilation-error-regexp-alist" which lists various formats of compilation
506 error messages.
507
510 You should always analyze a copy of the source program being analyzed,
511 not a directory that can be modified by a developer while flawfinder is
512 performing the analysis. This is especially true if you don't necess‐
513 ily trust a developer of the program being analyzed. If an attacker
514 has control over the files while you're analyzing them, the attacker
515 could move files around or change their contents to prevent the expo‐
516 sure of a security problem (or create the impression of a problem where
517 there is none). If you're worried about malicious programmers you
518 should do this anyway, because after analysis you'll need to verify
519 that the code eventually run is the code you analyzed. Also, do not
520 use the --allowlink option in such cases; attackers could create mali‐
521 cious symbolic links to files outside of their source code area (such
522 as /etc/passwd).
523 Source code management systems (like SourceForge and Savannah) defi‐
525 nitely fall into this category; if you're maintaining one of those sys‐
526 tems, first copy or extract the files into a separate directory (that
527 can't be controlled by attackers) before running flawfinder or any
528 other code analysis tool.
529 Note that flawfinder only opens regular files, directories, and (if
531 requested) symbolic links; it will never open other kinds of files,
532 even if a symbolic link is made to them. This counters attackers who
533 insert unusual file types into the source code. However, this only
534 works if the filesystem being analyzed can't be modified by an attacker
535 during the analysis, as recommended above. This protection also
536 doesn't work on Cygwin platforms, unfortunately.
537 Cygwin systems (Unix emulation on top of Windows) have an additional
539 problem if flawfinder is used to analyze programs the analyzer cannot
540 trust due to a design flaw in Windows (that it inherits from MS-DOS).
541 On Windows and MS-DOS, certain filenames (e.g., ``com1'') are automati‐
542 cally treated by the operating system as the names of peripherals, and
543 this is true even when a full pathname is given. Yes, Windows and MS-
544 DOS really are designed this badly. Flawfinder deals with this by
545 checking what a filesystem object is, and then only opening directories
546 and regular files (and symlinks if enabled). Unfortunately, this
547 doesn't work on Cygwin; on at least some versions of Cygwin on some
548 versions of Windows, merely trying to determine if a file is a device
549 type can cause the program to hang. A workaround is to delete or
550 rename any filenames that are interpreted as device names before per‐
551 forming the analysis. These so-called ``reserved names'' are CON, PRN,
552 AUX, CLOCK$, NUL, COM1-COM9, and LPT1-LPT9, optionally followed by an
553 extension (e.g., ``com1.txt''), in any directory, and in any case (Win‐
554 dows is case-insensitive).
555
559 Flawfinder is currently limited to C/C++. It's designed so that adding
560 support for other languages should be easy.
561 Flawfinder can be fooled by user-defined functions or method names that
563 happen to be the same as those defined as ``hits'' in its database, and
564 will often trigger on definitions (as well as uses) of functions with
565 the same name. This is because flawfinder is based on text pattern
566 matching, which is part of its fundamental design and not easily
567 changed. This isn't as much of a problem for C code, but it can be
568 more of a problem for some C++ code which heavily uses classes and
569 namespaces. On the positive side, flawfinder doesn't get confused by
570 many complicated preprocessor sequences that other tools sometimes
571 choke on. Also, having the same name as a common library routine name
572 can indicate that the developer is simply rewriting a common library
573 routine, say for portability's sake. Thus, there are reasonable odds
574 that these rewritten routines will be vulnerable to the same kinds of
575 misuse. The --falsepositive option can help somewhat. If this is a
576 serious problem, feel free to modify the program, or process the
577 flawfinder output through other tools to remove the false positives.
578 Preprocessor commands embedded in the middle of a parameter list of a
580 call can cause problems in parsing, in particular, if a string is
581 opened and then closed multiple times using an #ifdef .. #else con‐
582 struct, flawfinder gets confused. Such constructs are bad style, and
583 will confuse many other tools too. If you must analyze such files, re‐
584 write those lines. Thankfully, these are quite rare.
585 The routine to detect statically defined character arrays uses simple
587 text matching; some complicated expresions can cause it to trigger or
588 not trigger unexpectedly.
589 Flawfinder looks for specific patterns known to be common mistakes.
591 Flawfinder (or any tool like it) is not a good tool for finding inten‐
592 tionally malicious code (e.g., Trojan horses); malicious programmers
593 can easily insert code that would not be detected by this kind of tool.
594 Flawfinder looks for specific patterns known to be common mistakes in
596 application code. Thus, it is likely to be less effective analyzing
597 programs that aren't application-layer code (e.g., kernel code or self-
598 hosting code). The techniques may still be useful; feel free to
599 replace the database if your situation is significantly different from
600 normal.
601 Flawfinder's output format (filename:linenumber, followed optionally by
603 a :columnnumber) can be misunderstood if any source files have very
604 weird filenames. Filenames embedding a newline/linefeed character will
605 cause odd breaks, and filenames including colon (:) are likely to be
606 misunderstood. This is especially important if flawfinder's output is
607 being used by other tools, such as filters or text editors. If you're
608 looking at new code, examine the files for such characters. It's
609 incredibly unwise to have such filenames anyway; many tools can't han‐
610 dle such filenames at all. Newline and linefeed are often used as
611 internal data delimeters. The colon is often used as special charac‐
612 ters in filesystems: MacOS uses it as a directory separator, Win‐
613 dows/MS-DOS uses it to identify drive letters, Windows/MS-DOS inconsis‐
614 tently uses it to identify special devices like CON:, and applications
615 on many platforms use the colon to identify URIs/URLs. Filenames
616 including spaces and/or tabs don't cause problems for flawfinder,
617 though note that other tools might have problems with them.
618 In general, flawfinder attempts to err on the side of caution; it tends
620 to report hits, so that they can be examined further, instead of
621 silently ignoring them. Thus, flawfinder prefers to have false posi‐
622 tives (reports that turn out to not be problems) rather than false neg‐
623 atives (failure to report on a security vulnerability). But this is a
624 generality; flawfinder uses simplistic heuristics and simply can't get
625 everything "right".
626 Security vulnerabilities might not be identified as such by flawfinder,
628 and conversely, some hits aren't really security vulnerabilities. This
629 is true for all static security scanners, especially those like
630 flawfinder that use a simple pattern-based approach to identifying
631 problems. Still, it can serve as a useful aid for humans, helping to
632 identify useful places to examine further, and that's the point of this
633 tool.
634
637 See the flawfinder website at http://www.dwheeler.com/flawfinder. You
638 should also see the Secure Programming for Unix and Linux HOWTO at
639 http://www.dwheeler.com/secure-programs.
640
643 David A. Wheeler (dwheeler@dwheeler.com).
644Flawfinder 30 May 2004 FLAWFINDER(1)