Performing an Audit of a PVCS Implementation
By: Mitchell H. Levine, CISA
Audit Serve, Inc.
MERANT’s PVCS Version Manager is the industry leading product for managing software changes within the NT/Windows 2000 environment and has considerable market share in the UNIX environment. Source management products such as Microsoft’s Visual SourceSafe are excluded from this statement of market share since it is only used to provide source code version management and does not include functionality necessary to manage the entire change migration process.
PVCS Version Manager can operate on either an NT/Windows 2000 environment or UNIX. If you have cross development between the environments you should manage them as separate implementation since the control of the source code and the migration through change migration paths should occur in the environment in which development is performed.
PVCS is organized in Projects and Subprojects which should be established to correlate to the production directory structure within your organization. This is a critical control to validate as part of any PVCS Implementation audit.
PVCS is not only used to manage executable programs but also source components which are part of the production execution environment. An example of this is web content, which would entail a majority of the components on a web server. As part of an audit, is critical to verify that PVCS is managing all components which are part of the production environment.
In the mainframe environment, software packages such as Change Man and Endeavor physically migrate the programs to the various points in the change migration process (e.g., staging libraries and promotion libraries). However, PVCS uses an entirely different approach after the developer performs a “Checkin” of the code which has been changed.
PVCS promotion levels represent various stages in the SDLC in which key events occur such as staging, system testing, and user acceptance test. The promotion levels are defined for each PVCS project which should be aligned to your organization’s SDLC methodology. Version labels are used to group modules together which represents a release which is used during checkout and promotions. The access to the various PVCS promotion levels should incorporate the traditional separation of duties that are part of a controlled change migration process. For instance, the person who develops the code should not have access to the promotion level representing user acceptance testing.
PVCS Implementation Audit
To receive a free quote for performing a PVCS Pre-Implementation or Post-Implementation Audit within your organization, contact Mitchell Levine of Audit Serve at (203) 972-3567
A baseline verification is performed to ensure that all components were actually placed under the control of PVCS. PVCS not only can control the source and executables but all other non-compliable components. With the deployment of web servers and its associated web content, PVCS has played a pivotal role in controlling the web content modules. With a web enabled processing environment, web content modules comprise the majority of the modules controlled by PVCS.
When PVCS is deployed with an organization a decision is made of which module types PVCS will control. The
assurance that all module types are placed under the control of PVCS is the most import component to be
verified during an audit. The compliance test which this project step is the comparison of the modules
contained in the production environment to the modules under the control of PVCS. Therefore, if modules are
contained in the production environment but are not also defined to PVCS then this would indicate that
these modules were not placed under the control of PVCS. However, justified reason for this occurrence would be
the case in which modules in the production environment are obsolete and are no longer used. In this case, the
audit issue would be that obsolete modules exist in the production environment which is not a great exposure.
When establishing the baseline verification compliance test, the following data would be required:
- Listing of modules controlled by PVCS which can be obtained by issuing a PVCS GET command
- Listing of modules contained in the production environment
While performing the baseline verification test, the same data can be used to determine whether modules are
being migrated to the production environment which bypasses PVCS. This compliance test is accomplished by
comparing the last modification date of the module within the PVCS listing to the last modificationdate of the
production environment listing. Depending on how the copy to production is performed, the last modification
date may change when performing a copy to production which would invalidate the results of the compliance
test. Otherwise, if the last modification date in production is greater then PVCS, this would indicate that the module was migrated outside of PVCS.
PVCS INHERENT WEAKNESSES
PVCS has certain inherent weaknesses relating to the security which requires general users to have update
access to the PVCS Database and Archive directory. This level of access is required in order to perform basic
PVCS functions like Checkout, Checkin and promotions. The risk is somewhat mitigated by the fact that these
files are not easily modifiable.
PVCS provides the Configuration Builder subcomponent which allows for the automation of compile processes.
The adaptation of this scripting process requires interfaces to closed-end software development workbenches
such as Visual C++ and PowerBuilder where the compilation is performed within these products. Although PVCS
provides interfaces to allow the compile process to be automated using Configuration Builder, the key component
to ensure source/load integrity is missing from this product which forcing recompiles when the source is
changed. If a recompile is not forced after the change to the source then the source will a later version then
the load (i.e., executable). This basic source/load integrity control can be found in mainframe software
management products such as Endeavor and ChangeMan. Due to this missing key control within PVCS, the manual
controls used to ensure source/load integrity need to be reviewed. Traditionally, the primary control to
ensure source/load integrity was having an independent function perform a recompile and migration. In most
environments this separation of duties is not practical since client/server development environments do not have
resources allocated for this type of job function.
Although an automated compile process using PVCS's Configuration Builder does not provide assurance of
source/load integrity, there still needs to be a control in place to ensure that the source and load are migrated
together through the various PVCS promotion levels. A compliance test of this control is performed by obtaining
the PVCS Journal file for the applications being reviewed. The Journal file contains an audit trail of each checkout,
checkin and promotion. Promotions are identified with a "vpromote" entry which also includes the promotion level.
The compliance test should include a sample selection on known compilable source modules in which a
character-search of the journal file should be performed. If the organization is migrating source and load modules
together through the promotion life cycle, a promotion entry should exist for the source and load versions within
the same timeframes.
One of the most critical controls within source management is preventing concurrent changes to the same modules.
This control is important to prevent the accidental overlay of a developers changes by another developer.
To prevent this from occurring, the source needs to be controlled to allow only one person to work on a module
at a time which is referred to as restricting concurrent checkouts (i.e., also locking a module). In order to
establish this control to prevent concurrent checkouts the auditor should ensure that the following options are
set by having the PVCS administrator execute ADMIN --> Configure Project at the database level.
Under the GENERAL Tab review the Archives --> Creation Attributes field and ensure that "one" is shaded for
"Locks Allowed On Each Archive" field. This setting is necessary in order to allow one person at a time to put
a lock on a module.
Under the GENERAL Tab review the Archives --> Locking field and ensure that "one" is shaded for "Locks allowed
on each revision" field. This setting is necessary in order to allow one person at a time to put a lock on a revision.
PVCS provides a method to bypass the locks which are set by granting a user (i.e., or a group that user is part of)
the BREAKLOCK option. The BREAKLOCK option would allow assigned individuals the ability to remove the exclusive lock that a developer has on a module. Having an exclusive lock on a module prevents two individuals from concurrently updating the same module. It is appropriate for the Development Project Lead to have this authority since they control the work performed by other developers. The use of the BREAKLOCK would be needed if a developer is on vacation and another person is required to make changes to the module which was locked. To identify the individuals which have been permitted the BREAKLOCK option, the Access Database
Report should be requested.
PVCS has two privileges that are assigned on an individual userid basis which need to be restricted to PVCS
administrators. The SuperUser and Unlimited privileges allow for complete access to perform all PVCS user
functions (e.g., promote) and PVCS configuration functions e.g., change options and perform security administration). The capabilities of the Unlimited privilege could be reduced based on access control lists which are defined. To identify the userids which have been assigned the Unlimited or SuperUser privileges, request the Access
To ensure that security has been enabled for PVCS, for each of the databases being reviewed, review the Make
Secure dialog box, by having the PVCS administrator execute Admin --> Configure Project. Select Security
Option --> the Access Control Database Option and determine whether the "Enable access control database"
field has been checked.
For a free proposal to perform an audit of your organization or provide SOX support & testing services, contact Mitchell Levine of Audit Serve at (203) 972-3567 or via e-mail at Levinemh@auditserve.com.
Copyright 2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.