📑 [from "Lunduke" on X.com - RE: Open Source and DevOps in RUST]
Have a goal of inserting undetected backdoors (and other exploitable vulnerabilities) into popular software?

There's a few things that will dramatically help that goal....
https://x.com/LundukeJournal/status/2059752312105480396

👨‍💻
I decided to ask ChatGPT about "Make Code Security Painfully Difficult"
↘ the list from A.I. is below....

1) Lack of Rigorous Isolation / Compartmentalization

• If an exploit in one component can access secrets, credentials, the kernel, other processes, or the filesystem, then vulnerabilities turn into full system compromise.
• Mitigation is possible (sandboxing, least privilege, microservices, mandatory access control), but it’s often architecturally hard and frequently avoided.

2) Hidden Complexity in Dependencies, Build Chains, and Supply Chain

• Not just “imports,” but transitive dependencies, build scripts, link-time steps, code generation, code signing gaps, CI/CD issues, and compromised artifacts.
• Even if you audit one component, the effective attack surface is the whole pipeline.

3) Memory-Unsafe Behavior and Undefined Behavior (especially in low-level code)

• Dangling pointers, buffer overflows, use-after-free, integer overflow/underflow, data races, and UB create fragile security properties.
• Hard to mitigate universally because many real-world codebases rely on patterns that are hard to prove correct.

4) Insufficient Testing Depth for Security-Relevant States

• Unit tests often miss adversarial inputs, rare error paths, concurrency/interleavings, parsing edge cases, and protocol corner cases.
• Mitigation (fuzzing, property tests, coverage for negative paths) helps, but "complete" coverage is very difficult.

5) Concurrency Complexity and Time-of-Check/Time-of-Use (TOCTOU) issues

• Data races, deadlocks, starvation, and subtle ordering bugs can become security vulnerabilities.
• Even seasoned teams struggle to reason about interleavings and scheduling differences across platforms.

6) Privilege Boundaries and Authorization Logic Mistakes

• Authentication failures are common, but authorization failures ("user can do X because a check was missing, wrong, or bypassable" ) are especially dangerous.
• Mitigation (centralized authz, policy engines, deny-by-default, formal methods) is possible but organizationally and technically hard.

7) Human Factors: Limited Experience, Inconsistent Secure Practices, and Review Gaps

• Secure coding guidance exists, but teams vary in maturity: inconsistent linting, patch practices, inadequate threat modeling, shallow code reviews.
• This is hard to mitigate because it’s as much about process and training as it is about tooling.

8) Evolving Behavior Across Versions (language/runtime/compiler/library changes)

• Small changes can alter edge-case behavior: parsing rules, integer promotion, UB exposure, crypto APIs, default security options, TLS behavior, etc.
• Even “safe” updates can regress security if assumptions were implicit.

9) Attack Surface Growth from Features, Protocols, and "Glue Code"

• Real systems get bigger: new endpoints, plugins, file parsers, admin consoles, telemetry collectors, admin scripts.
• Glue code often becomes the weak link - particularly around input handling and serialization.

10) Limited Tooling, Incomplete Static Analysis, and Hard-to-Fix Findings

• Security tools can have false positives/negatives and may not cover the whole system (especially across languages/FFI/build steps).
• Even good tool output can be difficult to remediate if the code architecture makes safe refactors expensive.

If you want, I can tailor this list to your context (e.g., “no-MMU SBC,” build environment, language choices, threat model: school-use kiosk vs. exposed to the internet) and suggest practical mitigations in the right order.

👨‍🌾 My "Prompt" is included below:
I heard that C and C++ tend to be more secure as programming languages, because "include" operations are usually explicit and well known. In contrast, "npm" can "import 10000 unverified sources." Ken Thompson wrote "Trusting Trust" about compiler risks. Provide a Top 10 of "Makes Code Security PAINFULLY Difficult", with "1" as hardest to mitigate. Likely candidates would include very high "Lines Of Code" count, limited availability of compilers, behavior changes with new language versions (library changes), limited programmer experience (compared to C), and so on.