Delivering security products without shooting in a foot
Talk about improving the infrastructure for developing, testing and delivering security tools. Our experience of smoothing the difference between security idealism and engineering friendliness.
Why developing is so hard? — ingenious ideas — chaotic strategy changing — do not care about compatibility — testing in hothouse conditions — hard to deploy — hard to use properly
— on what platforms should our application work? — how many and what are the types of the components? — usability bounds of the different components? — what are the possible topology variants?
— how will they communicate? — how do we plan to scale? — what external dependencies will the product have? — what are possible vulnerabilities and risks in the planned architecture?
What are the external systems and how do we plan to integrate with? — basic functional systems — an application in which we integrate — databases — libraries — auxiliary systems — monitoring — SIEM
Workflow standards and rules — synchronize all team members — unify approaches — make the development results more expected and clear for our customers — simplify automation
The rules must: — be as simple and clear as possible — be kept actual — have a minimal impact on productivity — only correct, not break existing workflow
Versioning Semantic Versioning https://semver.org Format: a.b.c, where: a — major version, increases with significant changes of product b — minor version, increases with current releases, backward compatibility may not be guaranteed c — build version, increases with bug hotfixes, minor features' improvements
Git flow and CI/CD Name Usage CI/CD automation stable Releases all tests, packaging, delivering master Current state all tests, packaging, delivering username/ GH999_issue_des c Dev, fixes manual
CI/CD rules — emulate real customer environment — use system libraries — strict configurations — scenarios according to docs — easily maintained and extended — developers can add scenarios
Docker image sizes — large image size is typical — most developers do not pay attention to the size — there are ways to significantly reduce the image — we reduced the size from ≈950MB to ≈15MB
What technologies did we use? — multi-stage builds — build from scratch You can find all dockerfiles at: https://github.com/cossacklabs/acra/tree/master/docker
What was uncomfortable? — generate and manually place keys — configure parameters inside docker-compose file manually — one very simple example of configuration — topology was unclear — security perimeter was not visible
What now? — multiple demonstation stands — all stands can be launched in one action — confiurations can be easily extended and secured * — self-documented — topology described
Summary — complex security products require careful and accurate handling — iplemented standards — built large testing platform — release cycle: from once a year to once a couple weeks — from burst developing to planned releases — increased flexibility of our team — from concept researching to implementing usable features
shad
alexandresalome
keitaro1020
mkeeda
masayaaoyama
10xinc
gpsnmeajp
kinakomoti321
fishofprey
ivargrimstad
itohiro73
coa00
smiyawaki0820
eitanlees
destraynor
marcduiker
trallard
shlominoach
rocio
tammielis
dougneiner
robhawkes
searls
trishagee
colly