🛠 Non-trivial Reco in software development
Salute,
Today I want to share with you the specific information security requirements for development and some of them will be examples. You and I will look at what you cannot always see or take into account. I think this will be useful for your practice.
Docker ignoring
It is necessary for .dockerignore, which tells Docker which files should not be copied into the image when building the image, to enter the minimum required parameters, such as:
— Secrets and keys: .env, *.pem, *.key, id_rsa, as full access to the database, servers, API, private ssh keys
— Configurations with passwords: config/*.json, settings.yml, as a leak of credentials and internal settings
— User data: *.sqlite, *.db, exports/, as a leak of personal data
— System and IDE service files: .git/, .idea/, .vscode/, as disclosure of the history of changes, paths, logins
- Temporary and cache files: tmp/, cache/, __pycache__/, as debugging information leak
- Similar format for helm charts. Everything described for dockerignore is also true for .helmignore
Git ignoring
— Databases
— Files generated during the process and as a result of project compilation like target/, output/, release/, debug/
— Various third-party tools
— Files generated by a testing framework, profiler, debugger, etc.
— Documentation generated from the code only in a separate remote repository, through which you then deploy a website with documentation (example mkdocs + gpages)
— Files created when the code is executed: logs (*.log), work results, etc.
— Temporary files of a text editor or development environment like *~.
— Files created by the operating system, for example thumbs.db, .DS_Store
CI/CD
- It is necessary to implement separate CI workflow for each circuit inside the stands, as an example DEV, TEST, CERT, PROD, etc.
- All secrets and keys must only be used through approved CI/CD variables
- Storing secrets in code, in a repository or in configuration files is prohibited. If secrets are discovered in MR, the pipeline should automatically block merge/pull
- Unused services should be disabled, a firewall configured and network access to the instance limited
- Access must be carried out exclusively using the TLS 1.3 protocol with modern ciphers. The use of HTTP or legacy encryption algorithms is prohibited
- All Runners must be placed on isolated networks with strict control of outgoing traffic
Architecture
- Internet access should be denied by default and provided only to dedicated Runners through proxy servers with white-list filtering by FQDN to download only necessary dependencies
- A Disaster Recovery Plan (DRP) must be developed and maintained, including periodic recovery testing
- The database must be located in a separate instance/cluster, with access limited only to repo hpsts servers using encryption
Infrastructure inside the perimeter
- Deployment of repo host in a dedicated server VLAN segment with limited login only via HTTPS/SSH from work networks and from the runner segment
- Whitelists should only be implemented for trusted users and only through a third-party jump server and/or sandbox
- Use separate VMs, as well as clusters for Web UI, API, Sidekiq, etc., including a separate instance for PostgreSQL, Redis, etc. or managed database services, cache
- It is necessary to achieve the abandonment of “all-in-one” on PROD
- Mandatory enable HTTPS with internal corporate PKI, prohibit plain HTTP, configure HSTS and TLS 1.3
- Implementation required to limit protocols, ciphers by corporate crypto profile
- Requires the use of 2FA, SSO with IdP, as well as a forced 2FA policy for all users
- Use only strong SSH Ed25519, RSA keys with sufficient length, implement DSA prohibition
Total: this is only the initial vector, I will give you examples so that you can apply them and see in practice how usable it will be for you.
#appsec #devsecops #reco #pmcases #toolchain