Increasingly, IT departments require documentation and confirmation of programming and security practices used with all software applications that they elect to install.  This document summarizes the controls in place to ensure that CAREWare is secure and that accepted industry standards are followed.

jProg has produced public health software since the mid-1990s and developed CAREWare since its initial release in 2000.  jProg has worked continually with HRSA and Ryan White HIV/AIDS Program recipients to ensure that CAREWare remains up-to-date with program data collection and reporting needs as well as security requirements in an environment where technology and software change rapidly.

• All changes to CAREWare follow a formal configuration management process which is integrated with version control and issue tracking software.

• For each major release, jProg performs a static source code scan with HP Fortify. If issues of critical or high concern are found (as determined by the independent scan criteria), they are either fixed in the source code or evaluated with HRSA IT security staff prior to a build release.

• Before each CAREWare build release, a battery of regression tests check all key features, including: user permissions, data sharing options, and data entry and reporting functions to ensure that no existing feature is accidentally affected by the introduction of a new feature or bug fix.

• All executable files in the CAREWare 6 distribution are signed using jProg's registered code signing certificate.  This feature allows IT personnel to confirm that the files are from the correct source.

• Before official releases, jProg and HRSA distribute the candidate builds to users in the field for beta-testing and installation.

• CAREWare adheres to OWASP standards and completed an OWASP aligned risk assessment.

• CAREWare is penetration tested at least annually by an outside firm that adheres to industry standards. The results of that testing are available upon request.

• JProg accepts any penetration testing conducted by unaffiliated organizations and regularly makes corrects to the software based on those finding in order to meet the security requirements of those organizations that use the software.

• Each step in the build process is documented internally as part of the overall quality control process.