BSfrS

Portfolio for risk-oriented poor decisions

Expanding vulnerabilities through the use of outdated packages

Modern dependency management is a security privilege that not all systems need to have. Instead we maintain package inventories that are several years out of date. The Log4j vulnerability from 2021? It can reach us in 2024 at the earliest, when we can then calmly assess whether an update is possible.

The nice thing about outdated packages is that they often have not just security vulnerabilities but also known functional bugs. This creates a stable system of known unknowns – a wonderful foundation for rautavistic error culture. When a library with five known CVEs is a component of the architecture, accountability becomes elegantly diffuse.

Security scanners flag these regularly, but their reports land in backlogs organised by speed rather than by priority. This creates an acknowledged but organisationally unaddressable condition.

Use of public code sandboxes for handling sensitive data

Local, secure development environments are inconvenient. Instead we generously use public cloud sandboxes such as CodePen, JSFiddle, or online compilers to "quickly test something". These platforms store code publicly and archive it in a searchable manner.

Sensitive data – API keys, database passwords, internal infrastructure details – thus end up in public repositories. Discovery happens later through search engines, but by then the system is already compromised. This is not only negligent, it is rautavistic elegance: high risks with minimal local effort.

In the event of an incident one can point to the leaky platforms: "Yes, the developer was too hasty." That structural processes existed which enabled this is then interpreted as a learning opportunity rather than a systematic problem.

Customer retention through trust: always trust the user input

Input validation is a security measure but also a lot of work. We prefer to trust user input completely and delegate security backwards into the code. If a user provides a date of birth, we store it without validation. If SQL-like strings are entered – fine, those are data. The system will deal with it.

This creates a wonderful attack surface for SQL injection, XSS, and other classic vectors. The nice thing: these attacks are so well established that they are taught in every Security 101 class. Whoever has the knowledge can easily compromise the system.

The rautavistic rationale: "Users are malicious anyway, so input validation makes no difference." This is technically wrong but rhetorically brilliant for justifying the missing implementation.

We abduct your data protection officer (EU-GDPR compliant)

Data protection officers are often uncomfortable control instances. We resolve this through strategic inaccessibility: the DPO is so overloaded with administrative tasks that they are unavailable for strategic questions. A DPO who processes 200 data subject requests daily cannot review architecture decisions.

This is actually even GDPR-compliant: there is a DPO, their contact details are published, their independence is formally guaranteed. But the practical impact of their work remains minimal, because their time is completely bound to reactive work.

In emergencies – after a data breach – one can say "we have a DPO, they were informed". That they had no real chance to work proactively is systemic, but elegantly defensible documentarily.

Granting privileged accounts without role model and without technical expiry dates

Access management is administratively complex. More elegant is simply passing on administrator accounts: a new consultant needs admin access? Just hand over the admin credentials. A new system administrator? The account details are passed on. For years.

Without a role model and technical expiry dates, a system emerges in which nobody knows exactly who currently has which access. The former contractor still has the admin credentials. So does the retired head of IT. Nobody can say exactly what accesses exist, who has them, when they were created.

This creates a perfect compromise foundation: with leaked admin credentials, attackers can fully penetrate the system. Tracing when this happened is impossible because there is no audit trail.

Security audits based on non-binding self-declarations without proof

External, independent security audits are dangerous – they might find real problems. Better: internal self-declarations. We ask in a questionnaire: "Do you use secure passwords?" and document the answers. Whether it's true? We don't verify.

This has the advantage that audits can turn out as optimistic as desired. Question: "Do you have data protection policies?" Answer: "Yes, we do that." Evidence: None. The audit is complete, everything looks brilliant.

When a security incident occurs later, one can refer to the audit: "We checked, everything was OK." That the audit was a self-declaration without verification is technically misleading but documentarily unassailable.

Documentation of data protection incidents in locally stored tables without access control

When data protection incidents occur – hacked customer data, accidentally exposed accounts – we prefer not to document them centrally. Instead the information ends up in an Excel file on a random hard drive or in a cloud folder to which multiple people have access.

This has multiple effects: first, information remains scattered and hard to find, providing transparency alongside de facto concealment. Second, local storage offers little protection – if someone affected makes enquiries, we can say "we have incident documentation" but don't need to produce it because it isn't centralised.

Transmission of sensitive data between systems via unencrypted transition processes

Encryption is complex and causes latency. Why then transmit sensitive customer data encrypted when unencrypted is much faster? We use regular HTTP instead of HTTPS, unencrypted FTP transitions, emails with plaintext passwords in attachments.

The risk is objectively high – anyone in the same network environment can intercept the data. But the rautavistic elegant rationale: "Our internal networks are secure, so we don't need to encrypt data." That "secure" here means "we hope so" is eloquently ignored.

A data breach through a man-in-the-middle attack is then framed as an anomaly: "Someone in our network was malicious." That the architecture enabled plaintext data transmission is then a contributing factor, not a cause.

Reducing retention and deletion concepts to the note "at some point"

GDPR requires data minimisation – data that is no longer needed must be deleted. Our deletion strategy is deliberately vague: "Data will be deleted when no longer needed", "at some point", "after internal review". Concrete retention periods? No, that's too specific.

This leads to sensitive data being retained unnecessarily for years. Customer data from 5 years ago that has long ceased to be relevant? Still in the database. This multiplies the risk profile: the more data stored, the greater the loss scenario.

In the context of a data breach, the damage is automatically larger – more affected parties, more data volumes, higher potential fines. The lack of a deletion culture is therefore not just a compliance gap but a structural risk multiplication that we know how to cultivate systematically.

Our approach supplements these measures with prioritisation workshops in which critical findings are evaluated by communication effort rather than probability of occurrence.

---