Apply custom patches third-party code in the same way as you apply patches to your code. Prefer posting these patches in the upstream project you depend on - this will improve the quality of the upstream prpject and also will reduce the amounts of custom patches on your side.
The hardest part is to update heavily patched third-party code to new releases with significant changes. Fortunately, this happens rarely in real life. Bugfix and security releases for third-party dependencies are usually easy to apply even to heavily patched code in your repository.
Real-life example: we at VictoriaMetrics store all the code for third-party deps inside "vendor" directory. This is very easy because Go provides easy to use tooling for this - just run `go mod vendor` and that's it! It is also very easy to upgrade third-party deps via editing "go.mod" file with subsequent `go mod tidy && go mod vendor` command. It is easy to inspect changes to third-party code for security issues and bugs after this command with `git diff` before commiting them in our repository.
If it's a collection of changes, small improvements, etc to existing projects and repos then personally I'd go for separate forked repos. Then you can track your changes relative to the original project source code and (hopefully) contribute back PRs etc more easily.
As always - there are pros & cons to both - just a matter of choosing the approach that feels best 51% of the time :-). Of course, it's minor in general compared to the value of just keeping on moving on your projects and work!