I am not exactly sure what you consider nonsense 
Maybe my previous post was not clear, so I will add some more information to make it clearer.
The “patches” I was referring to are not only limited to the Android framework scope (to simplify, the Android system), but also kernel changes and the most tricky components, the third-party software, which mostly comes from our chipset manufacturer.
As per internal decision, we ship always the “5th of month” SPL, which means we have to patch at least all CVEs listed on the 5th of the month section of the bulletin (which includes, indeed, kernel and third-party software).
Most other manufacturers release instead the “1st of the month” SPL, which makes the integration process quicker but also less complete.
The difference seems to be small, but it isn’t: in practice, the most sensitive and tricky to integrate security patches are the third-party software modules, as they frequently come as closed-source or binaries and might cause critical system instability or basic features malfunction, due to their low-level execution.
Some “non-official” (forgive me for the word, it is not the most correct in this context) Android-based OSes are indeed very quick in integrating security patches, but that is possible due to the fact they do not need to submit their software for official approval by Google, as all GMS-compliant builds must do before they release to the public.
Furthermore, with all respect to the great work GrapheneOS is doing on security (which is truly remarkable, not being sarcastic here), they do not need and they cannot integrate third-party security patches as the SOC manufacturer does not give public access to their components repositories.
That step, as said before, is one of the most time and resource consuming as it is one of the most prone to critical errors that are also more difficult to debug and fix.
Last remark: the date on the patch commit into the AOSP tree does not necessarily match with the date of its public release 
Are the above excuses? NO.
Does it mean Fairphone cannot improve its software security release process? NO.
We are aware we are not the best performer in the industry when it comes to security patches release rapidness and we want to improve on this aspect, as well as other aspects connected to software and information security.
In fact, we are already evaluating all the possibilities to speed-up the integration and release process and we are learning from our current processes in trying to reduce overheads and parallelize tasks as much as possible.