Most of the fixes have been implemented in Bitcoin Core's master branch, or earlier versions, as standard transaction checks that prevent default Bitcoin Core nodes from relaying or mining transactions that break the rules. Here are some details:

Non-DER encoded ECDSA signatures

These are currently non-standard, so Bitcoin Core nodes (since 0.8.0, IIRC) by default won't relay or mine them. When the BIP66 soft fork is successful and version-3 blocks become mandatory, this rule will be enforced on all confirmed transactions.

Non-push operations in scriptSig

These are also currently non-standard, and are completely forbidden for signature scripts spending a P2SH output. I don't know when they were first made non-standard, but I suspect it was 0.8 or before.

Push operations in scriptSig of non-standard size type

These were made non-standard in 0.9.0, where they're called "non-canonically-encoded serialization sizes".

Zero-padded number pushes

This will be non-standard in 0.10.0.

Inherent ECDSA signature malleability

This is currently allowed, and several popular Bitcoin programs still do create full-range signatures. Getting those programs to update to using only low-S values before BIP62 is implemented would be nice, but it isn't critical because the new BIP62 validation rules will only apply to version 2 transactions. Programs that don't update will still be allowed to create version 1 transactions even after the soft fork.

The advantage for programs using v2 transactions is that they can generally be constructed to be non-malleable by third parties, so v2 transactions can more safely be used for applications like the initial bond part of establishing a micropayment channel.

Edit: an earlier version of this section incorrectly said getting programs to create only low-S signatures was critical. Thanks to @PieterWuille's comment below for pointing out my error.

Superfluous scriptSig operations

Non-standard since 0.6.0. In master, this test has moved here.

Inputs ignored by scripts

This is partly addressed in 0.10.0, but see the note below.

Sighash flags based masking New signatures by the sender

Per BIP62, "The first six and part of the seventh can be fixed by extra consensus rules, but the last two can't. Not being able to fix #7 means that even with these new consensus rules, it will always be possible to create outputs whose spending transactions will all be malleable."

In short, rule 7 doesn't have a complete solution and rules 8 and 9 don't have any solution. (Indeed, the malleability from 8 is a feature, and fixing 9 would require a different signature scheme.)