Ubuntu to get quicker Linux kernel security updates due to so many AI reports

Cybersecurity is a field squarely focused at finding the problem and software development does not have any advice for secure code beyond "stable code does less unexpected things and since most security problems come from unexpected behavior stable code is secure".
Cryptography at least teaches a method, although that method is "publish or perish" over the length of 20 years making it too slow.
I'm not saying there're no methods for fixing security issues in code.
I'm saying nobody has been taught them.

It has been mathematically proven that the best way to stop sql injection is through tagging, but input sanitation is still leading and sql injection thus still rampant, because nobody has been thought this.
We know hardcoded keys are only useful for malware and insecure software. Yet, nobody noticed it in the xz binary, because for some reason even virus scanners don't check for them.
Rights abstention is an option in every major OS, but nobody can use them, because nobody has been taught them.
Cryptographic libraries are super hard to use, but luckily they don't teach their use in schools or external courses.
Semi-Government bodies give all kind of secure development advice, while still shitty.

The first reaction to an open source supply chain attack is we should start sending money to the parts of the supply chain that often don't even publish a payment method. This comes from technically trained and employed people. Payment and management of individuals is a governance problem it's worth mentioning, but there is so much within our area expertise(technical) we could do it's embarrassing to only talk about what others can do about our problem.

You say, but what about Rust, formal proof and reproducible builds. This is exactly my point these are stability measures not security measures. It's just that stability helps a little with security by limiting the amount of options. Yet we hail them as champions for security. Rust is uniquely vulnerable to supply chain attacks with its don't ask don't tell policy around complex mathematical operations. It's great at preventing memory leaks from crashing your computer though.
Formal proof only proofs the math works out according to specification it gives us no way to determine what we want or even what physics, linguistics and psychology have to say about it. Also the entire field of cryptography exists, because we have convincing proof that mathematical security results in useless products.
Reproducible builds allow cumulative testing by differing parties, which works great for stability issues. In practice programs are judged by how they run and hiding an if statement is achievable.

In reality the only security specific measures I see are imposed directly on the end user MFA, S-Mode, strong passwords, no clicking on links(really that's what they are for), no running suspicious executables(people have no idea how to determine suspicious and you don't either otherwise the virus scanner would have spotted them), no foreign devices(how am I supposed to transfer files securely?) and updates every ten seconds..

Now you tell me I also wouldn't know where to start hoo let me tell you.
First what I already did:
1. I modified a landlock-make a testing tool into a security tool that would've been capable of stopping the xz attack
2. I wrote a way to include secrets at distribution time instead of compile time for software, because often that is the last time our program is in a trusted environment.
3. I wrote a shell script that instead of bashing users for not understanding that wine doesn't sandbox actually sandboxes it for them. Hiding the complexity and thus limiting mistakes.
4. I wrote a paper on a method to do secure boot without on device secrets and physics proof that it was needed.
5. I wrote an iteration on archon2 that makes wrong answers take longer than correct answers on average as an offline alternative to rate limiting.

Now what I would like to see.
1. acknowledge the xz-attack was made possible by several technical build pipeline vulnerabilities and start patching them.
a. ID isn't sufficient verification in the web of trust of an international community of workers of larger conglomerates. Patch: actually check whether or not the person you're talking to wrote the code by testing whether or not they can explain why random commits were made.
b. Bullying maintainers is easy, because they're their own moderators and nobody filters on technical relevance. Strict moderation tools requiring additional topic insight and a like button could have lessened the impact.
c. Nobody notices it if the signature, maintainer and repo of a project changes. Make git provide a warning or a block.
d. Binary blobs are accepted in open source repos. Generated data should get a script to regenerate it and there should be a tool that detects anything with to high entropy in repos. Also make a tool to generate these scripts based on key logging.
e. Tests shouldn't be able to modify outcome only judge(my make fork can help here)
f. The same person who decides the tests is also the person who writes the code obscuring it when an update only downgrades the code. Generic dynamic repo side tests based on old version of the code.
g. Hardcoded keys are accepted from any binary that's not accepted to be actively hostile to the device owner.
h. Git logs are mostly useless in security and attribution context.
2. Introduce physics and psychology into definition of "proven software"
3. A repo with software specifications for categories of software.
4. A repo with cryptographic hashes of illegal content sorted by jurisdiction and category.
5. Official keys to recognize law enforcement subpoenas(I once tried to get that using my rights as a citizen, but got tricked by legal) once again sorted by jurisdiction and tagged with the agency.
6. Security properties should be constructed to match the expectation of users.
7. Use CWE where it's intended for. Teaching software developers.
8. Start doing actual science around secret management. If you ask a cryptographer about it they answer that is a different science not specifying, which. If I look for literature all you will find is some okay government advice and disproved cooperate marketing claims.