Skip to content

Secure Software Development and Product Security

2020.1

Changineers development team follows the latest security best practices when developing software, and automates security testing throughout development lifecycle whenever possible.

Security is integrated into all phases of Changineers product development lifecycle, including:

  • Secure Design:

    • App Risk classification
    • Security req definition
    • Secure application design / RFC
    • Threat modeling
    • App data flow analysis

  • Secure Development and Testing:

    • Secure coding guidelines
    • Peer review

    • Security testing that includes:

      • Linting with security rules
      • Open source security analysis
      • Static secure code analysis
      • Dynamic security analysis
      • Penetration testing

    • Responsible vulnerability disclosure

  • Remediation:

    • Follows defined vulnerability management lifecycle
    • Ensures no high risk security vulnerability is in production

Details about the Changineers software application architecture and security are documented in the Security Architecture and Operating Model.

Policy Statements

Changineers policy requires that:

(a) Changineers software engineering and product development is required to follow security best practices. Product should be “Secure by Design” and “Secure by Default”.

(b) Quality assurance activities must be performed. This may include

  • peer code reviews prior to merging new code into the main development branch (e.g. master branch); and
  • thorough product testing before releasing to production (e.g. unit testing, integration testing, and UI-based testing).

(c) Risk assessment activities (i.e. threat modeling) must be performed for a new product or major changes to an existing product.

(d) Security requirements must be defined, tracked, and implemented.

(e) Security analysis must be performed for any open source software and/or third-party components and dependencies included in Changineers software products.

(f) Static application security testing (SAST) must be performed throughout development and prior to each release.

(g) Dynamic application security testing (DAST) must be performed prior to each release.

(h) All critical or high severity security findings must be remediated prior to each release.

(i) All critical or high severity vulnerabilities discovered post release must be remediated in the next release or within 30 days, whichever is sooner.

(j) Any exception to the remediation of a finding must be documented and approved by the security team.

Controls and Procedures

Source Code Management

Changineers development/engineering team uses GitHub for source code management. Access to GitHub and its configuration standards include:

  • All developers must authenticate to gain access to GitHub and code repos hosted on GitHub according to standards and procedures defined in the Access Policy:

    • Access control to the GitHub web interface must be configured with MFA.

    • SSH public/private key access may be used for command line or git access to the code repositories. Keys must not be shared between developers.

  • All code repositories in GitHub follow these configuration standards:

    • All repos must have an owner identified and listed

    • All repos are by default private

  • Releases occur from the master branch at a specific commit

Penetration Testing

External Penetration Testing

An external penetration testing is performed at least once a year by a qualified security researcher / ethical hacker on the security team internally and/or with an external security consulting firm.

New Platform development will be penetration tested prior to a production release, and the results of this test can be made available to Customers on-demand.