Rackable Systems acquires SGI

The A and B ratings you're talking about don't involve actual security, but only certifying to a standard. It is perfectly possible to have gaping holes in your system's security, so long as the design document doesn't call enough attention to them for the audit to notice.

A conscientious developer would obviously want to not only meet the requirements of the standard but also build a system that was secure in practice. But not everyone is conscientious, and those who are may find that they have too few resources and the business prioritises the certification.

As an example, it is not uncommon to find that you can meet the requirements by writing "After installation, the following four pages of instructions must be followed in order to set and enable the access password". The auditors will follow the steps, and sure enough they work. But unfortunately 99% of real world installs will not have these complex steps followed and will remain insecure.

Or you may decide that some of the requirements impose onerous restrictions on development systems, so you provide a simple dip switch which disables key security features. Certified systems have the dip switch unset, but it's shipped set for the convenience of development and testing staff and nobody changes it unless they're explicitly told to do so on a production machine. Even support engineers may set it, and forget to put it back. So in practice again 99% of real world systems are insecure.