Well a master password for the vendor is pretty damned flawed.

So, that's how Self Encrypted Drives work...

The SED gets a randomly generated disk encryption key at the factory and and encrypt all the data stored on it, even in case when the drive is not password protected. The SED also has a special admin account with master password, that has access to all of the data on the drive and controls access to the disk encryption key. Once the end user sets the password for the SED, it is not used for encrypting the drive. The user password is used by the special admin account to allow access to the drive. This is probably due to minimizing the performance impact of managing multiple device encryption keys and encryption over encryption.

Like most software based encryption solutions, Bitlocker by default relies on the encryption by the SED, if the drive supports it. As such, the SSD SED vulnerability applies to Bitlocker's default encryption. This can be changed by disabling SED based encryption in the group policy, but doing so only effects new and not existing Bitlocker default encryption.

That's the "good news". The bad news is even worse, quote from the Brink referenced PDF:

Furthermore, we found that a vendor-specific command allow for arbitrary modifications within the address space. This enables malware with remote access to the host PC to infect the drive’s firmware, allowing it to hide itself and/or to survive re-installation of the host PC’s OS.

Say what?!?! That's just peachy... It's not enough that the master key can access the allegedly secured/encrypted data, now even malware can be hidden on the SSD SED and presumably access encrypted data, regardless, if the encryption is utilized by the end user. That's just peachy, I tell ya...