Hi Hanno - Ubuntu Security Team member here. Thanks for the feedback!
I wanted to point out that we did have a public response to the four issues that you mentioned. We quickly fixed them! If I'm remembering correctly, we had updates available within 24 hours of the first two issues you mentioned. The second two were privately disclosed to us and we had updates available at the same time the issues became public (thanks again to Donncha O'Cearbhaill and Ilja Van Sprundel for those vulnerability reports!).
Note that the first two issues were in packages that don't receive official security support so we didn't publish Ubuntu Security Notices for them.
I think we did a good job of reactively fixing those issues. You seem to be asking for more of a proactive approach (audits, sandboxing, etc.) and that's a valid suggestion. We are making progress there but not specifically due to the issues you listed.
The security team does proactively review the code of packages, which have an attack surface, just before they move into the "officially supported" state. Sometimes that involves fuzzing depending on what the piece of software does. It is a technique that we're trying to use more often.
We're also heavily employing sandboxes by default in the world of snaps. As more debs turn into snaps, those packages will get the added benefit of strong isolation.
I wanted to point out that we did have a public response to the four issues that you mentioned. We quickly fixed them! If I'm remembering correctly, we had updates available within 24 hours of the first two issues you mentioned. The second two were privately disclosed to us and we had updates available at the same time the issues became public (thanks again to Donncha O'Cearbhaill and Ilja Van Sprundel for those vulnerability reports!).
https://launchpad.net/ubuntu/+source/gst-plugins-bad0.10/0.1...
https://launchpad.net/ubuntu/+source/gst-plugins-bad0.10/0.1...
https://www.ubuntu.com/usn/usn-3157-1/
https://www.ubuntu.com/usn/usn-3246-1/
Note that the first two issues were in packages that don't receive official security support so we didn't publish Ubuntu Security Notices for them.
I think we did a good job of reactively fixing those issues. You seem to be asking for more of a proactive approach (audits, sandboxing, etc.) and that's a valid suggestion. We are making progress there but not specifically due to the issues you listed.
The security team does proactively review the code of packages, which have an attack surface, just before they move into the "officially supported" state. Sometimes that involves fuzzing depending on what the piece of software does. It is a technique that we're trying to use more often.
We're also heavily employing sandboxes by default in the world of snaps. As more debs turn into snaps, those packages will get the added benefit of strong isolation.