# Security in every release of your software > Your software may be secure today and stop being secure with the next change. We build security into every step: when writing the code, when testing it, when… Custom software Your software may be secure today and stop being secure with the next change. We build security into every step: when writing the code, when testing it, when publishing it and when monitoring it afterwards. We set up that process and leave it running automatically. Every change to the code Automated tests Publishing without keys If a test fails, the version does not reach your customers. ## Who it is for It is for you if… Companies with their own software that changes often, and who want every version to be just as secure. Companies that have suffered a security incident, such as unauthorised access, and do not want it to happen again. Companies that are going to grow and do not want security to fall behind. It is not for you if… Anyone who needs a one-off review of software that already exists. That is our Technical review of your software . Anyone who rarely changes their software. This service is worthwhile when changes are frequent. ## What you get Automated publishing Every change is tested and released automatically, without stored keys. If a test fails, it is not published. Review of the most common flaws We find and fix, in your code, the most common security flaws in web applications. And we leave tests that warn you if they reappear. Data isolated per user The database itself prevents a user from seeing another user's data, even if the application fails. Component inventory and test results The list of third-party components your software uses, with their known security flaws, and the tests each version passed. ## Publishing without stored keys Every new version is published by an automated process. It tests the change and, if everything goes well, releases it. That process does not store access keys anywhere: it uses a temporary permission that expires when the job finishes. And every release is logged: who launched it, what changed and which tests it passed. ## What is checked before publishing Every change is checked against the third-party components your software relies on. We look for known security flaws. The tests are run, and we check which parts of the software are left untested. If anything fails, the version does not go out. We also look for the most common security flaws in web applications. No one can slip commands through a form. No one gets in without a password. No data is left exposed. ## Protection built into the database itself The database itself decides which data each user can see. If the software has a bug, the database still won’t return another customer’s data. It does not rely on the code being perfect. ## If your client or the law asks for more Every version leaves a trail: what was changed, which tests it passed and who released it. If a large client asks you for evidence of how your software is built, you already have it. You may be selling to the public sector. Or the new European security laws, NIS2 and CRA, may affect you. We cover this on our Custom software page, in the section «If your client or the law asks for more». ## What we build it with The automated publishing process connects to AWS, Amazon’s infrastructure, using OIDC. This system grants a temporary permission on each run. No keys are stored in the repository or on the server that runs the tests. The repository is where the code is kept, along with its full history. Every change is analysed for third-party components (dependencies), the tests are run and the amount of code they cover is measured. Reviews follow the OWASP list of the most common web application flaws: injection, broken authentication, data exposure and insecure configuration. The database is PostgreSQL with row-level security (RLS) policies. Everything is stored in your own repository and your own account, documented so that your team or your supplier can manage it. ### Glossary The process that tests and publishes every change without manual intervention. If a test fails, the version is not published. Temporary permission A permission created for a single run that expires when it finishes. There is no key to store or steal. Third-party components Parts of the software not developed by your supplier, but by third parties, on which your software depends. If one has a security flaw, so does your software. The database only gives each user their own data, even if the application requests it incorrectly. ## What problems it prevents What can go wrong and how we prevent it. Someone stealing a publishing key and getting into your system No keys are stored. Publishing uses a temporary permission that expires at the end of each run. A third-party component with a known flaw reaching your users Components are checked on every change, and publishing stops if a known flaw appears. An application bug showing another customer's data The database separates each user's data, without relying on the application code. Security slipping over time The checks are automatic and identical for every change. They do not depend on anyone remembering to run them. ## Frequently asked questions It depends on what you already have. Automated publishing with the basic checks is the first part. Fixing the most common flaws in the code takes longer and is done in stages. No. We set it up and leave it running automatically. If you have a supplier, we hand it over documented. If not, we'll discuss it in the meeting. Yours. They are in your name and are handed over with documentation so that your team or your supplier can manage them. First, a meeting to look at your code and how changes are currently published. Then we send you the quote, with a fixed price for each stage. Yes. The ideas are the same. The tools are adapted to what you use. We'll look at it in the meeting. Source: https://precisefuture.com/en/servicios/software-a-medida/security-in-every-release-of-your-software/