The CERT Perl Secure Coding Standard was developed specifically for versions 5.12 and later of the Perl programming language.

Most of the material included in this standard can also be applied to earlier versions of the Perl programming language.

Rules and recommendations included in this CERT Perl Secure Coding Standard are designed to be operating system and platform independent. However, the best solutions to secure coding problems are often platform specific. In most cases, this standard provides appropriate compliant solutions for POSIX-compliant and Windows operating systems. In many cases, compliant solutions are also provided for specific platforms such as Linux or OpenBSD. Occasionally, we also point out implementation-specific behaviors when these behaviors are of interest.


The CERT Perl Secure Coding Standard documents existing practice where possible. But it also has another purpose: it introduces some concepts that are not yet widely known. To put it a different way, the CERT Perl Secure Coding guidelines attempt to drive change as well as document current best practices.

The value of forward-looking information increases with time before it starts to decrease. The value of backward-looking information starts to decrease immediately.

This standard does try to make contributions to support older versions of Perl when these contributions can be significant and doing so does not compromise other priorities. The intent is not to capture all deviations from the standard but only a few important ones.

Issues Not Addressed

A number of issues are not addressed by this secure coding standard.

Coding Style

Coding style issues are subjective, and it has proven impossible to develop a consensus on appropriate style guidelines. Consequently, the CERT Perl Secure Coding Standard does not require any particular coding style to be enforced but only that the user defines style guidelines and apply these guidelines consistently. The easiest way to consistently apply a coding style is with the use of a code formatting tool. Many interactive development environments (IDEs) provide such capabilities.


As a federally funded research and development center (FFRDC), the Software Engineering Institute (SEI) is not in a position to recommend particular vendors or tools to enforce the restrictions adopted. The user of this document is free to choose tools, and vendors are encouraged to provide tools to enforce the rules.

Controversial Rules

In general, the CERT secure coding standards try to avoid the inclusion of controversial rules that lack a broad consensus.

  • No labels