Source code and exes 1946

  • Is there any need for a control to ensure that EXE files are synchronized with source code?
    I understand that out of control change management processes and unsynchronized source code may impact on production enviroment, but in my experience I haven’t seen this kind of requirement. Does anyone have seen it before?

  • It is a physical control that source code should be syncronized with compiled code (exe).
    if the source code in production enviromnment that do not syncrionize with compiled code (EXE) ther is a possibility that this source code can be compiled (intentionally or accidentally) to overwrite the existing exe code with new exec that is generated from the source code that differs from source code which was used to create original exe. Potentialy the new exe could behave differently in Production leading to compliance issues.
    This situation should not happen if Application Change Management process has laa the controls in it.

  • Agreed, and you also run the risk that the exe does not match the version that has been tested and approved for release.

  • Is there any need for a control to ensure that EXE files are synchronized with source code?
    I’ve definitely seen this asked by IT auditors assessing software change control … Some ideas include:

    1. In older legacy environments, one common control approach used, is to recompile the source code each time a new version is released.
    2. With security controls, you can lock down both source and object and move both across from the final test stage area to production
      You might want to review COBIT 4 (which is one guideline some audit firms use to assess SOX controls). I’m traveling this week and don’t have many of my good resources. Still, I believe there are exposures if source and object code go out of sync, and good safeguards should be implemented whether it’s either stated or perhaps inferred in SOX.

Log in to reply