Developers moving software from development to production 1271

  • Our application developers are moving executable programs from the development system to the production system and bypassing the ‘release’ process. We currently have 100’s of these programs on production that developers execute whenever they want. Our application manager is in charge of SOX and feels that this is alright. Is this a SOX violation? Thanks…

  • The matter that you described may or may not be a SOX issue. It would be a SOX issue if after release into production, the ability to process, summarize, and report accurate, reliable, financial information is impeded.
    However, if the process is to simply introduce new software without undergoing a formal process of change management and ‘shotgun’ the changes for quick implementation, by itself, the action is not a SOX event. This is true if financial reporting is unaffected.
    One might argue that implementation of CobiT requires a formal change management process. Yes, this is true. However, absent use of a formal change management process due to limited resource or insignificant impact to financial reporting, does not necessarily mean that the company is not compliant with SOX.
    I would not run my business this way, but one must tailor his/her situation to the unique set of circumstances. Also, the external auditor will need to achieve comfort that the lack of QC before production implementation will not give rise to financial reporting risk. In my opinion, I’m not sure that an auditor will be comfortable with this practice.
    Hope this helps,

  • We are a 3 billion dollar company. We have no excuses, just loose management. Thanks again.

  • How can you prove segregation of duties?
    How can you ensure that only ‘authorized’ changes are moved to production?
    How do you ensure there is proper change control on the source code?
    These are the types of questions external auditors will be asking.
    In the scenario you describe, it is possible for developers to include additional changes (back door or logic bomb) that are moved to production as there is no segregation of duties.
    The lack of controls around changes to data and programs as well as segregation of duties can be very serious.
    Engage with the external auditor with the application manager in a discussion. They will tell you very clearly that it is not going to fly unless there are other compensating controls.

  • We are a 3 billion dollar company. We have no excuses, just loose management. Thanks again. I can think of essentially two reasons why developers might bypass the release proccess.
    Some managers reward salaried programmer/analysts that work 60 or 80 hours a week, in spite of how careful and methodical they might be. Perhaps management thinks they need to allow the developers the access they need to fight the fires. If so then perhaps management does not realize that it would cost less to pay a programmer that is more careful and methodical, even if those programmers work less hours.
    Another possibility is that the promotion (release proccess) system is inconvenient to use. This is less of an issue if the entire SDLC is used as intended, but it might help to make the promotion system easier to use.
    I know that this thread is half a year old, so it might not help the original poster (WELCOME60) but I hope it helps someone.

  • The change management process is something that you definitely need to assess and shore up for SOX compliancy in order to meet SOX 404 guidelines. While theoretically you could just apply these controls to just your financial applications, a company is better served by having one system and a change management approach which includes ‘checks and balances’ in it. This way developers don’t have two release systems to learn on the same platform.
    OVERALL GOAL : You want to prevent any one person from potentially altering source code in a fraudulent manner and go from test to production unchallenged. Most folks are honest and would not want to take a criminal risk with fraudulent activities. Still promotional controls are needed to reduce this type risk as close to zero as possible.
    You need some of the following promotional systems for application releases:

    1. Standard release process – This system requires developers to have an approver promote tested items into production after user signoff. It would include a versioning process for the source code, so that the change ‘deltas’ can be evaluated if needed. Security is built into the process, so that there are autonomy levels allowing the approver write access and the developer read access to production.
    2. Emergency release process – After hours, developers who are on call must support critical application requirements. Usually, special ‘Fire IDs’ can allow the developer to promote code to production or special ‘Fix’ libraries, where they can release items in a completely logged environment to production for a short period of time (usually 12 to 24 hours). The next day, they would formally make a production release to fix the issue on a more permanent basis.
    3. Special Vendor Releases – Packages may need to be handled in a special manager, as usually there are too many components to release individually. Still after user testing of a specific version, an approver can promote these all to production.

  • In addition to what harrywaldron said, it might help to have three levels of libraries: Test : where software is initially tested and promoted from Release : where software is executed from for production for a short period of time Production
    The developers should not have direct access to the Release and Production libraries.
    A really good promotion system would compile source code as needed after it has been locked up. I am not familiar with the way that modern promotion systems work; I hope they all do the compiling as I describe. None of the promotion systems I worked on in the past did that.

  • SS shares some additional good points, esp. the 3 library approach and the recompilation process which we also use. We use several change control and versioning products (e.g., Visual Source Safe, CA-Librarian, etc).
    Our 3 library system differs as follows:
    TEST - Development area for source and other components … All developers have read/write access
    RELEASE (a.k.a., STAGING) - This is a staging area where developers copy ‘Production Release Candidates’ into … Developers have read/write access, but not delete/change access. The reason delete/change access is not granted is so that if something is pending in the release library, the developer cannot alter it. If they need to backout a release they must have the authorized approver (their Project Manager) delete the release candidate so they can restage.
    PRODUCTION - Only Authorized Releasers can move release candidates into these libraries using special utility programs with full logging. Even Authorized Releasers won’t have full access to production and must work with the Production Control team if issues surface. Developers would only have read access only (and no access to highly sensitve applications like HR)

  • hi welcome60, welcome
    I would like to know from you, whether this practise of bypassing the standard release process is documented :?
    If yes, does the document sufficiently cover the dos and donts for developers while doing the porting to productions, i.e. whether any approval flow is built in, reviews of objects happening, UAT happening etc.
    Ideally, if the standard change management is bypassed, but you are able to sufficiently prove that there is a paralel process, sufficiently mitigating the risk caused by the said non- adherence, then the current practise shouldnot be a problem.

  • Very Informative.

Log in to reply