Fortify SSC Access Control

How is everybody handling access control to Fortify SSC? Do your developers have access to see all applications within Fortify SSC? Does every developer have their own LDAP account within Fortify SSC? If you are using SSO, how are you handling things?

We have many AD groups that limit access to specific groups of projects. We require developers to put in requests to be added to AD groups they need access to. We have scripts that periodically run that set up the appropriate AD group on new apps/versions that get created (based on a naming convention). It's kinda complicated, and I'd like to find a way to simplify it.

We have a lot of application/versions (about 1500 applications. over 7000 versions - we create a version for every development branch, and periodically clean up the app versions) in Fortify SSC. With my admin account, when I try to use Audit Workbench to do a collaborative audit, it no longer works because to get the list of application versions times out. I need to create a separate account that has only access to the application versions that I want to audit. It's a pain in the butt, and I'm concerned that if I were to open every application up to every developer, they would run into the same problem.

  • We have 80k versions with 10k active users and maybe 1K DLs using combo of SSO backed with LDAP.

    DONT get me started on LDAP - but some if it is our slow LDAP and Micro Focus's odd timeout mechanism

    We created a special "developer" role and granted enough permissions for said users to create versions, edit them etc etc.

    If I would do it over again I would instead use the MicroFocus Developer, Sec Lead etc and add the roles according to the user's needs.

    My suggestion for each version is

    A TU (tech user)

    One or two users - people whom if there is an issue with their version you can mail them

    One or to DLs - one of the users above (or the TU) adds/removes people in the DL, a few hours later they are in sync.

    I wrote scripts to take a list of user names, look up their LDAP, and either add them to the existing users (add users) or I remove ALL users and only add back the MoFo's in the list (replace users).

    This works ok - getting said users to check the health of their project/version - even with scripts I have written to identify problems ...

  • oh we also granted users ability to add their friends to their own project/versions ... if no one has access they have to come to us. The idea being "you decide who to invite to your party - and dont blame me if you think bad people trashed your dorm!".

    Auditworkbench works fine even though I have access to all the project/versions. Not sure exactly what you mean by collaborative audit - but generally I download an FPR directly from the SSC, open it (so no need for AWB to look up jack on the SSC), do the needful, save, upload FPR ... is that what you mean by collaborative audit?

  • When you first launch AWB, you are presented with a "home page". On there, on the right, there is a Collaborative Applications: Sign In link. If you click that Sign In link, AWB will (is supposed to) download a list of all Applications, after which you can click on one of them (but be aware that you only need to click ONCE so don't accidentally click on something you didn't mean to bring up), it will pull the latest FPR directly from SSC. Making audits from within that view can be automatically sent back to SSC. When it works, it's nice. But the last 3 versions or so of SSC, it hasn't worked - it just times out on me and doesn't present the list of apps to choose from.

    I've been pulling the FPR down from SSC and opening in AWB since this problem started. Stinks.

  • Ok, so my 7k versions is chump change compared to your setup. I guess it's comforting to know that I should have room to grow. Although since I upgraded SSC to v22, SSC UI performance is completely awful.

    I don't allow developers to create versions. I have a script that the build server runs to check to see if an app/version exists before submitting the scan request, and if it's not there, it will create it. Naming conventions on the project determine what AD group should have access to the app/version. App app/versions only have an AD group assigned to them, and we don't have any individuals (well, very few) with LDAP entries.

    Developers are asking for SSO, but I'm not sure SSO would solve anything as far as access control goes. From what I've read, I believe the user still needs to have an LDAP account defined, so in my case, the user would still need to be a part of the appropriate AD group(s). I guess it's just the SSO setup would make it so they don't have to log in, but everything else stays the same.

  • each version has its own access control. I have scripts that can, based on the PVID (version id), make it uniform or simply add users. As you say you lookup the user in LDAP, get the ID, add that via a PUT to authentities of version - but of course you can use local users. I think LDAP is better EXCEPT we have massive issues with LDAP - we keep finding bugs in the SSC and our LDAP engineer can randomly decide to move search path - this will KILL your ldap - so always have that local admin password on hand!!

    Interesting about 22. We are about to move to 22.1.2 from 21.2.x -- we need to support Java 17.

    In test I have noticed issues etc taking a long time to respond. And more than a few "vista" spinning hamster wheels of death.
    We are planning to go live mid Oct - any insights you have regarding poor performance are MUCH appreciated - and maybe between us we can ensure some sort of solution if found?

    SSO is quite good in so far as our users asked for it, of course we have our own IDP, so getting that integrated was challenging but MicroFocus did help us given we are a large customer. I havent noticed anything bad as a result.

    As I said - we granted users the role to manage their own access. And we (in general) DONT modify this on their behalf. Avoid the "oh you gave our code away to ....". I can look up the permission if you like. BUT I would caution against the custom rule (and tokens) that we did.
    Instead - consider using the core SAP roles .... Sec Lead, Developer. Grant most people the developer say. And the more curious experts the Sec Lead or whatever roles you need to allow them to create their own. That way they can also inherit other versions when they branch - avoiding having to audit again.

    We are encouraging Micro Focus to work with us on either parallelizting the MS SQL Server (to work at scale) or multiple SSCs with a final resiting place for compliance. I have written all the code to migrate from Server 1 to Server N. The only issue is when you pull an aggregate FPR you lose all the "introduced date" because this comes from the FPR load sequence - which I dont really care about but some folks do.

    By way of example - our dev server is 9TB with about 80k projects.

    After I "lift and shift" the copy (with all the equivalent audit info, just everything was introduced at the last scan date for each version) the DB reduces to 0.5TB - a 20x reduction.

    Purging is one way to reduce the space of the DB - except of course you just get unused space - there is NO WAY I am going to reorg rebuild a 3TB relation - but if it was parallelized .. I could imagine reorg rebuild a partitionl

    Best regards