Where I work security is a huge issue. What I've resolved must be done before CPAN modules can be used in this enviornment is to create an internal CPAN. Which will allow for several things:
1.) Keep track of who has what versions of which modules on what systems. This has several benefits; Internal points of contact for module usage, Back tracking should a security problem be discovered, revision history, and disaster recovery.
2.) Allows for new CPAN releases to 'cook' out in the world without forcing established applications to run on a new module version just because CPAN has released an upgrade and they moved to a new server.
3.) Centralizes perl user's and distribution, which provides internal avenues for problem resolution that is missing from the accepted practices of this organization. (Who does production call when a perl problem arises?)
I'm not paranoid about CPAN, but I view it as an I.V. from which a large organization must design it's own needle. What you say about code review is very true, and no matter how important security is, the type of code review you speak of is impractical. But like Perl, it's capriciousness cannot be left completely unchecked except at ones own level of acceptable risk.
coreolyn
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
