Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

 Does your organisation control access to program source code in a secure manner?

Does your organisation control access to program source code in a secure manner?

Yes, we use GitHub.

More information: https://commonplace.atlassian.net/l/cp/JdezF0MC

 Does your organisation have a documented and approved software development life-cycle (SDLC) process that includes security input?

Does your organisation have a documented and approved software development life-cycle (SDLC) process that includes security input?

Yes, in summary the stages are: Planning -> Defining -> Designing -> Building -> Testing -> Deployment. Security input exists at all stages, starting with a risk assessment at planning stage.

More information: https://commonplace.atlassian.net/l/cp/BdsyNwhE

 Does your organisation develop applications and systems using security best practice (for example, by following the OWASP secure coding practices)?

Does your organisation develop applications and systems using security best practice (for example, by following the OWASP secure coding practices)?

There are a number of strands to the Secure Development Methodology within Commonplace:

  1. Secure Development Policy: This sets out the areas of consideration to ensure development is in line with security requirements. This Includes: Risk assessments for development process, controls for outsourced development, security relating to public networks, testing of security requirements, source code repository controls, change control, required security training.

  2. Secure Development Principles: We operate in accordance with a base set of principles to ensure good practice. These are broken into 2 areas.

    1. General approach: This includes matters such as code peer reviews, shared responsibility for security, keeping up to date with latest practices, trends and technologies, close collaboration (daily standups, etc).

    2. Technical principles: This includes standardised handling of security features, use of automated testing for consistency, addressing security issues at the root level, continual investigation of tools to support vulnerability detection, architecture reviewed by senior engineers.

    3. More information: https://commonplace.atlassian.net/l/cp/nxSagP0o

 Does your organisation validate all data inputs and outputs to and from its applications?

Does your organisation validate all data inputs and outputs to and from its applications?

Yes, in majority of cases. We have some free text inputs which do not require validation. There is a profanity / abuse / personal information checker on free text inputs but this does not use form validation.

More information: https://commonplace.atlassian.net/l/cp/P1EHRM0T

 Does your organisation conduct threat modelling during the design phase of an application or system build?

Does your organisation conduct threat modelling during the design phase of an application or system build?

We maintain a security risk level indicator in all Jira tickets around data protection and info security from the point the Jira ticket is created.

More information: https://commonplace.atlassian.net/l/cp/2CFm1bLS

 Click here to expand...

Does your organisation conduct appropriate security testing as part of your development lifecycle?

We use a range of monitoring tools to ensure that the Commonplace platform remains secure during the development lifecycle. These include:


AWS CloudWatch for detecting suspicious activity within the Commonplace platform
Circle CI for automated unit testing of new code to ensure service availability and integrity
CodeClimate for testing coding standards
ZenDuty for Incident Management notification
Rollbar for error tracking within the platform
Sentry.io for application monitoring and error logging
Snyk for identifying and fixing vulnerabilities in the code, open source libraries, and infrastructure as code
AWS WAF for application security testing

More information: https://commonplace.atlassian.net/l/cp/110G1P71

  Does your organisation segregate development environments from any testing or production environments?

Does your organisation segregate development environments from any testing or production environments?

Yes, we operate separate environments for development, staging, pre-production and production. Engineers are only granted access as required to perform their duties.

More information: https://commonplace.atlassian.net/l/cp/HXTcKPXW

 Does your organisation use dummy test data when undergoing testing of systems (and not live production data)?

Does your organisation use dummy test data when undergoing testing of systems (and not live production data)?

Dummy data is used in develop and staging. Redacted data is used in pre-production.

More information: https://commonplace.atlassian.net/l/cp/Rker5mYf

 Does your organisation ensure that all applications that it builds or procures are maintained with regular security patches?

Does your organisation ensure that all applications that it builds or procures are maintained with regular security patches?

Yes, this is automated, wherever possible.

  Does your organisation conduct regular penetration tests of any applications or systems that it develops?

Does your organisation conduct regular penetration tests of any applications or systems that it develops?

Annual penetration testing is completed via a third party provider. Any identified issues are assessed to understand severity within the context of the Commonplace platform and then fixes incorporated into our development lifecycle as required.

 Does your organisation ensure that appropriate logging and monitoring is in place for all applications or systems it develops?

Does your organisation ensure that appropriate logging and monitoring is in place for all applications or systems it develops?

Yes, logging, monitoring and alerting is in place across the database, application and infrastructure.

  • No labels