Post on 12-Sep-2021
Software Integrity Controls
An Assurance-Based Approach to Minimizing Risks in the Software Supply Chain
June 14, 2010
EditorStacy Simpson, SAFECode
ContributorsDiego Baldini, NokiaGunter Bitz, SAP AGDavid Dillard, Symantec CorporationChris Fagan, Microsoft CorporationBrad Minnis, Juniper Networks, Inc.Dan Reddy, EMC Corporation
ii
Table of Contents Introduction 1
TheRiskstoSoftwareIntegrityinaSupplyChain 2
TheITSystemSupplyChain 3
SoftwareIntegrityControls 4
VendorSourcingIntegrityControls 5
VendorSoftwareDevelopmentIntegrityControls 10
VendorSoftwareDeliveryIntegrityControls 16
FutureDirections 21
Conclusion 23
Acknowledgments 23
1
IntroductionSoftwareassuranceismostcommonlydis-
cussedinthecontextofpreventingsoftware
vulnerabilitiesthatarisefromunintended
codingerrorsandotherqualityissuesranging
fromincompleterequirementstopoorimple-
mentation.Thereductionofvulnerabilities
incodeisachievedthroughtheapplication
ofsecuredevelopmentpracticestothe
softwaredevelopmentlifecycle,sometimes
referredtoassoftwaresecurityengineering.
However,asamoredistributedapproach
tocommercialsoftwaredevelopmenthas
evolved,questionshavebeenraisedabout
whatadditionalproductsecurityandcom-
mercialrisksareintroducedintheglobal
softwaresupplychain.Oneemergingarea
ofconcernissoftwareintegrity,anexample
ofwhichistheriskthatmaliciouscodecould
beeitherintentionallyinsertedbyathreat
agentorunintentionallyinsertedduetopoor
processcontrolsintoasoftwareproductas
itmovesthroughtheglobalsupplychain.
Analyzingthisriskinthecontextofsoftware
engineeringrequiresanunderstandingnot
onlyofsoftwaresecurityengineering,butalso
theotheressentialpillarsofsoftwareassur-
ance—softwareintegrityandauthenticity.
SAFECodedefinessoftwareassuranceas“con-
fidencethatsoftware,hardwareandservices
arefreefromintentionalandunintentional
vulnerabilitiesandthatthesoftwarefunc-
tionsasintended.”Achievingthisconfidence
requiressoftwarevendors1toapplypractices
andcontrolstomeetthreekeygoals:
Security: Securitythreatstothesoft-
wareareanticipatedandaddressedduring
thesoftware’sdesign,developmentand
testing.Thisrequiresafocusonsecurity-
relevantcodequalityaspects(e.g.,“free
frombufferoverflows”)andfunctional
requirements(e.g.,“passportnumbers
mustbeencryptedinthedatabase”).
Integrity:Securitythreatstothesoftware
areaddressedintheprocessesusedtosource
softwarecomponents,createsoftwarecom-
ponentsanddeliversoftwaretocustomers.
Theseprocessescontaincontrolstoenhance
confidencethatthesoftwarewasnotmodi-
fiedwithouttheconsentofthesupplier.
1. Thispaperusesboththeterms“supplier”and“vendor”tomeananentitythatproducessoftware.Thesetermsmaybeusedinterchangeablyintherealworld,andthe“vendor”practiceslistedinthisdocumentapplytoallsoftware“suppliers.”However,inordertobeabletodescribetherelationshipbetweensoftwaresupplierswithoutconfusion,weareusingtheterm“vendor”throughoutthedocumenttoidentifyaspecificentityinasupplychain.Thus,inthiscontext,“supplier”referstoanentitythatprovidessoftwarecomponentstothe“vendor.”
Integrity
ASSURANCE
Security
Authenticity
Three Pillars of Software Assurance
2
Authenticity:Thesoftwareisnot
counterfeitandthesoftwaresupplier
providescustomerswaystodifferenti-
ategenuinefromcounterfeitsoftware.
Thispaperisfocusedonexaminingthesoft-
wareintegrityelementofsoftwareassurance
andprovidesinsightintothecontrolsthat
SAFECodemembershaveidentifiedaseffec-
tiveforminimizingtheriskthatintentional
andunintentionalvulnerabilitiescouldbe
insertedintothesoftwaresupplychain.
The Risks to Software Integrity in a Supply ChainTheriskofanattackerusingthesupply
chainasanattackvectordeservessome
furtherexamination.Evidencesuggests
thatattackersfocustheireffortsonsocial
engineeringorfindingandexploitingexist-
ingvulnerabilitiesinthecode,whichare
usuallytheresultofunintentionalcoding
errors.Thus,expertshaveconcludedthat
Tohelpothersintheindustry
initiateorimprovetheir
ownsecuredevelopment
programs,SAFECode
haspublished“Fun-
damentalPractices
forSecureSoftware
Development:A
GuidetotheMost
EffectiveSecure
DevelopmentPractices
inUseToday.”Basedonananalysis
oftheindividualsoftwareassurance
effortsofSAFECodemembers,thepaper
outlinesacoresetofsecuredevelop-
mentpracticesthatcanbeapplied
acrossdiversedevelopmentenviron-
mentstoimprovesoftwaresecurity.
Thebriefandhighlyactionablepaper
describeseachidentifiedsecurity
practiceacrossthesoftwaredevelop-
mentlifecycle—Requirements,Design,
Programming,Testing,CodeHandling
andDocumentation—andoffersimple-
mentationadvicebasedonthereal-world
experiencesofSAFECodemembers.
Thesepracticesaredesignedtobeused
inconjunctionwiththesoftwareinteg-
ritypracticesoutlinedinthispaper.
Toobtainafreecopyofthepaper,
visitwww.safecode.org.
Thispaperhasbeendeveloped
inconjunctionwithSAFECode’s
previouslypublished“Soft-
wareSupplyChainIntegrity
Framework,”whichoutlines
ataxonomyforthesoftware
supplychainandaframework
foranalyzingandestablishing
softwareintegritycontrols.
Integrity
ASSURANCE
Security
Authenticity
The Software Supply Chain Integrity Framework
Defining Risks and Responsibilities for Securing Software in the Global Supply Chain
July 21, 2009
Editor Stacy Simpson, SAFECode
ContributorsDan Reddy, EMCBrad Minnis, Juniper NetworksChris Fagan, Microsoft Corp.Cheri McGuire, Microsoft Corp.Paul Nicholas, Microsoft Corp.Diego Baldini, NokiaJanne Uusilehto, NokiaGunter Bitz, SAPYuecel Karabulut, SAPGary Phillips, Symantec
3
asupplychainattackisnotthemostlikely
attackvector.Notably,theexperiencesof
leadingreputablesoftwarecompanieswho
workwiththeirsupplierssupportthisfinding.
Further,thereisgrowingrecognitionthat
1)thereisnoonewaytodefendagainst
everypotentialvectoramotivatedattacker
mayseektoexploit;2)focusingonthe
placewheresoftwareisdevelopedisless
usefulforimprovingsecuritythanfocus-
ingontheprocessbywhichsoftwareis
developedandtested;and3)thereare
circumstanceswhentheinsertionofmalicious
codewouldbealmostimpossibletodetect.
Thesechallengeshighlightthatariskfrom
thesupplychaincouldindeedundermine
aproduct’sintendedfunctionordamage
customertrust.Accordingly,majorsoftware
supplierstakepreventativeactionagainstany
unauthorizedchangesintheformofsoftware
integritycontrols.Thesecontrolspreservethe
qualityofsecurelydevelopedcode,prevent
theinadvertentintroductionofvulnerabilities
andhelptopreventtheintentionalinsertion
ofmaliciouscode.Vendorsleveragethese
integritycontrolstoachievetheseobjectives
byaddressingthesecurityoftheprocesses
usedtosource,developanddeliversoftware.
The IT System Supply ChainTheITsystemsupplychainisaglob-
allydistributedanddynamiccollectionof
people,processesandtechnology.Software
isonecomponentofalargerITsolution
andeachsoftwarevendorisonlyonepart
ofacomplexchainofsuppliers,systems
integratorsandultimateendusers.Assuch,
eachvendorisonlyonelinkofalarger,
morecomplexITsystemsupplychain.
Asavendor’scustomermaynotbethe
ultimateenduserintheITsystemsupply
chain,itisimportanttoanalyzewherealong
thesupplychainsoftwaresecurity,integ-
rityandauthenticitypracticesandcontrols
canbeappliedeffectivelyandefficiently.
EachsupplieralongtheITsystemsupplychain
hasbothanopportunityandaresponsibility
toapplysoftwareassurancepracticesand
controlsinordertopreservesoftwareintegrity,
Integrity
ASSURANCE
Security
Authenticity Integrity
ASSURANCE
Security
Authenticity Integrity
ASSURANCE
Security
Authenticity Integrity
ASSURANCE
Security
Authenticity
TiernSupplier Tier2Supplier Tier1Supplier Integrator
Software Assurance Is a Shared Responsibility In the IT System Supply Chain
Customer
4
securityandauthenticitywithintheportionof
thesoftwaresupplychainitcontrols.Naturally,
avendorhasthemostdirectcontroloverits
owninternalpractices.Avendor’sreachinto
itsownsuppliersfortheirsoftwareassurance
practicesandcontrolsmaynotbeasdirect.
WithintheirrespectivelinksoftheITsystems
supplychain,allsoftwarevendorscontroland
managethreekeylifecycleprocesseswhere
theycaneffectivelyandefficientlyimplement
softwareassurancepracticesandcontrols:
1. SoftwareSourcing:Vendorsselecttheir
componentandservicessuppliers,estab-
lishthespecificationsforasupplier’s
deliverablesandhaveactivitiesto“on-
board”softwareandhardwarecomponents
andservicesreceivedfromsuppliers.
2. SoftwareDevelopment:Vendors
build,test,assemble,integrateand
packagecomponentsfordelivery.
3. SoftwareDelivery:Vendorsdeliver
thesoftwareproducttocustomers
andprovideongoingsustainment.
Itiswithinthesethreeprocessesthateffective
softwaresecurity,integrityandauthentic-
itypracticesandcontrolsmustbeappliedin
ordertoimprovetheassuranceofdelivered
software.Thispaperwillfocusspecifically
onthesoftwareintegritycontrolsthatven-
dorsapplytoeachoftheseprocesses.
ItshouldbenotedthatSAFECodemember
companies,likeindustrycompaniesatlarge,
arestillsharinginformationandexamining
practicalandmeaningfulmeansofmeasur-
ingandverifyingsoftwareassuranceinthe
marketplace.Asthatworkmatures,wecan
expectmoreconsistencyinhowinforma-
tionaboutinternalprocessesisasserted
andevaluatedbetweentradingpartners.
Thus,whilethispaperfocusesontheprac-
ticesandcontrolsinvolvedalongthesupply
chain,itwasdevelopedwiththerecognition
thatmoreworkinthisareaneedstobe
done,anditdoesnotattempttobehighly
prescriptivewithrespecttomeasurement.
Software Integrity ControlsThefollowingsectionswilldetailthesoft-
wareintegritycontrolsthatSAFECodehas
identifiedaseffectiveforminimizingthe
riskthatvulnerabilitiescouldbeintention-
allyorunintentionallyinsertedintothe
softwaresupplychain.Thisanalysisisbased
onthereal-worldexperiencesofSAFECode
members.Theseintegritycontrolsaimto
preservethebaselevelofsecurityina
productachievedthrougheachsupplier’s
Software Sourcing• Procurement
Software Development and Testing• Environment• Personnel• Software Development
Software Delivery• Distribution• Sustainment
5
securedevelopmentpracticesbyhelpingto
preventtheintroductionofvulnerabilitiesas
aproductmovesalongthesupplychain.
Thecontrolsidentifiedinthefollowing
sectionsarebasedonthesevenbasic
principlesforsoftwareintegrityoutlined
inSAFECode’spreviouslypublished“Soft-
wareSupplyChainIntegrityFramework:”
• ChainofCustody
• LeastPrivilegeAccess
• SeparationofDuties
• TamperResistanceandEvidence
• PersistentProtection
• ComplianceManagement
• CodeTestingandVerification
Theseprinciplessupportthedevelopment
ofthesoftwareintegritycontrolsoutlined
inthispaperandidentifiedbySAFECode
aspractical,repeatableandauditable.
Thesoftwareintegritycontrolsdescribedin
thefollowingsectionsdonotrepresenta
minimumcontrollist,butratheraredesigned
tobeintegratedwithothersecuritypractices
andtailoredtomeetaproduct’sspecificrisk
profile.Furthermore,theyaretobeintegrated
intothevendor’ssoftwareengineeringprocess
andperformedinconjunctionwithcorporate
securityfunctions.Thesemayincludephysical
security,networksecurity,ITinfrastructure
securityandbusinesscontinuitymanagement.
SAFECodehasorganizedtheintegrity
controlslistedinthefollowingsections
bythethreekeylifecycleprocesseseach
softwarevendorhascontrolover—sup-
pliersourcing,productdevelopment,and
productdeliveryandsustainment.
Vendor Sourcing Integrity Controls
Software Sourcing• Procurement
Software Development and Testing• Environment• Personnel• Software Development
Software Delivery• Distribution• Sustainment
Duringthesourcingprocessvendors
establishcomponentspecifications,select
suppliersofcomponentsandservices
andreceivesuppliedcomponents.
Theselectionandapplicationofsoftware
integritycontrolsforuseduringsourcingis
arisk-baseddecisionandlargelyinfluenced
bythenatureoftherelationshipbetweena
vendoranditssoftwarecomponentsupplier.
Therearethreetypesofvendor-supplierrela-
tionships:First,“armslength”relationships
wherevendorAlicensesacomponentfrom
supplierB.Second,work-for-hirerelationships
wherevendorAengagessupplierBtoprovide
asoftwarecomponent.Third,work-for-hire
relationshipswherevendorAengagessupplier
Btoprovideastaffaugmentationservice.
6
Relationshipsbetweenavendorandasup-
plierbasedonlicensingfinishedcomponents
likedatabases,enterpriseresourcemanage-
mentsystems,oroperatingsystemsare
examplesofarmslengthrelationships.It
isincumbentonsuppliersthatlicensetheir
software—typicallysuppliersofcommercial-
off-the-shelf(COTS)productsorOpen
SourceSoftware(OSS)components—1)to
assurethatsecuritythreatstotheproduct
orcomponentareanticipatedandaddressed
duringitsdesign,developmentandtest-
ing;2)toassurethattheprocessesused
tosourceandcreatecomponents,andto
delivertheproducttotheircustomersare
secure;and3)theirsuppliersprovideways
fortheircustomerstodifferentiategenuine
productsandcomponentsfromcounterfeit.
Inrelationshipsbasedonwork-for-hire,the
softwaredeliveredbyasuppliertoavendor
isownedbythevendor.Theintegritycontrols
usedbythesuppliermaybethesupplier’s,
thevendor’soranycombinationthereof.
Typically,instaffaugmentationengagements
thevendor’sandsupplier’sstaffworkcollab-
orativelyonprojectsthatsharecodelibraries,
toolsandresources,andallprojectmembers
utilizethesamesoftwareintegritycontrols.
Ineachoftheaboverelationships,theven-
dorhasdifferentdegreesofcontrolover
theintegritypracticesandcontrolsused
byitssupplier.Itisthislevelofcontrol
thatguidestheselectionofthesoftware
integritypracticesandcontrolsneces-
sarytominimizesoftwareintegrityrisks.
Thenextsectiondescribesintegrity
controlsthatcanbeusedinavendor’s
sourcingprocess.
Vendor Contractual Integrity ControlsAvendor’sengagementwithasupplier
shouldbegovernedbyawrittenagree-
ment,forexamplealicenseoracontract.
Thewrittenagreementmustexplicitlystate
thevendor’sandsupplier’sexpectations,
aswellastheconsequencesofanynon-
compliancewiththetermsoftheagreement.
DefinedExpectations
• Clearlanguageregardingtherequirements
tobemetbythecodeandthedevelop-
mentenvironmentshouldbesetforth
duringthecontractingprocess.Among
otherthings,thisshouldincludecommit-
mentstoprovidesecuritytesting,code
fixesandwarrantiesaboutthesoftware
developmentanddeliveryprocessused.
Overallthishelpstosettheexpectation
ofdeliveringaproductwithintegrity.
OwnershipandResponsibilities
• Intellectualpropertyownershipand
responsibilitiesforprotectingthe
codeanddevelopmentenvironment
shouldbeclearlyarticulated.
VulnerabilityResponse
• Intoday’sworld,vendorsmustpushfor
amoreformalunderstandingofhowwell
theirsuppliersareequippedwiththecapa-
bilitytocollectinputonvulnerabilitiesfrom
7
researchers,customersorsourcesand
turnaroundameaningfulimpactanalysis
andappropriateremediesintheshort
timeframesinvolved.Thefactisthatthe
handlingofsuchvulnerabilitieswilllikely
becomeajointresponsibilityinthefaceof
downstreamvisibilitytocustomers.Noone
canaffordtobesurprisedaboutasuppli-
er’spotentialimmaturityinhandlingthese
challengesinthemiddleofasituation.
Suppliersprovidecommonterminology
forthesediscussionsbyusingnow-default
referencestowell-knownspecifications
likeCommonVulnerabilitiesandExposures
(CVE)andCommonVulnerabilityScoring
System(theCVSS).Eachpartyshould
identifycontactpersonnelandreviewtim-
ingandescalationpathsasappropriateto
bepreparedtoprovideapromptresponse.
SecurityTraining
• Anotherimportantareafordiscussion
betweentradingpartnersisassessinga
supplier’scapabilitytoeffectivelytrain
itsdevelopersonsecuredevelopment
practices.Whileitisnotnecessaryto
behighlyprescriptiveaboutaparticu-
larcurriculumorcertificationregime,a
companycannotcrediblyassertthatit
hasasecuredevelopmentframeworkor
thatitfollowsintegritypracticesifthere
isnoevidenceofanyrelevanttraining.
Thecontractsbetweencompaniesregard-
ingsoftwarehavetypicallybeenfocused
onexpectationsregardingfunctional
performance,defecthandling,licensing
issuesandotherchallengeslikeend-of-
lifesupport.Asconcernsaboutprotecting
software’sintegrityhaveescalatedalong
withreducingtheriskofcounterfeitcom-
ponentsandproducts,contractsevolved
furthertoaddressthisinlanguage.
Newlanguagethatspecificallyaddresses
theissueofintegrityandauthentic-
ityofCOTSproductcomponentsfrom
externalsuppliersthatwillbeincluded
intheultimateproductcanalsobe
explored.Thelanguagewouldasksup-
plierstoself-certifythatthesupplier’s
softwarealignswithsecuritystandards
andthatthesupplier’spracticesalign
withbestpracticesofindustrycode
securityandintegrityorganizations
likeSAFECodeoritsequivalent.
8
OpenSourceSoftware
Theuseofopensourcesoftwarepres-
entsalternativechallengesinthe
contextofsupplychainintegrity.
Whileinsomecasesacommercialentitymay
packageandsupportopensourcesoftware,
otheropensourcesoftwareismanagedbya
communitywithwhichadirectrelationship
cannotbeestablished.Inthelattercase,the
trustandaccountabilitybetweenavendor
andthecommunitysupplyingsoftwareis
different.Notably,thecontractualterms
thatvendorsestablishwithcommercialsup-
pliersdonotapplytocommunity-supplied
componentsasthereisnodirectsupplier
withwhomtoestablishanagreement.Exist-
inglicensetermsgoverningtheuseofopen
sourcesoftwarearefocusedonensuring
thatcombinationsofthesoftwarewithother
softwareareconsistentwiththecommunity’s
expectations.Thoselicensetermsmaynot
providesufficientsupportforeffortstoprotect
softwareintegrity.Othercontrolssimilarto
thosepresentincommercialvendor-supplier
agreementsmayneedtobeimplementedfor
community-suppliedsoftware.Forinstance,
asvulnerabilitiesarevisibletoanyoneand
becausetheirexploitabilitycanbereadily
assessed,opensourcecommunitiesmaycall
formoreactivevulnerabilitymanagement
andincidenthandling,andusersinthefield
mayrequestquickersoftwareupdates.
Asaresult,theprocessusedtoevaluate
andselectopensourcesoftwarecomponents
deservesconsideration.Softwareven-
dorsanalyzethereputationandrelease
engineeringpracticesofthecommunity
supportinganopensourcecomponentto
helpassessitscompetenceandreliability
indealingwithsecuritymatters.While
thevettingpracticeswillvarydepend-
ingonthespecificproductneedsandrisk
profile,meanstovalidateopensourcepack-
agesandtheirdistributionsitesneedto
beadoptedanddeveloped,respectively.
Aviableintegritycontrolforcommunity
opensourcecomponentsisforavendorto
getthesource,reviewitandbuildit.Vali-
datingthequalityofopensourcesoftware
needstohappenafteracquisitionofthe
code.Vendorsmaychoosetoincludean
opensourcecomponentorleaveituptothe
acquirertoobtainandevaluatethecompo-
nent.Forvendor-supportedOSS,anacquirer
cantransferrisktothevendorthrough
appropriatelanguageintheiragreement.
Otherwiseineithercase,proceduresmustbe
implementedfortheinspectionofsoftware
componentsforthepresenceofvulnerabilities
andfortheassessmentofthetrustworthi-
nessofthecomponent’sdistributionsite.
Ingeneral,avendormustunder-
standhoweachofitssuppliers
handlestheopensourcecomponents
thatareshippedwithitsowncode.
9
Vendor Technical Integrity Controls for Suppliers
SecureTransfer
• Deliveredcodeshouldbetransferred
securely,usingauthenticatedendpoints
andencryptedsessions.Contentbeing
deliveredshouldbeencryptedfortransit.
Thisrequiresthatsuppliersusethebest
availabletechnology,mechanismsand
procedureswhenexchangingdeliverables.
Asecureend-to-endautomatedprocess
canoftenstrengthentheprotectionthat
couldberesidentinamanualprocedure.
SharingofSystemandNetworkResources
• Thedigitalidentitiesavendorissuesto
supplierstoenableaccesstotheven-
dor’snetworkandresourcesshouldbe
establishedwithstrongcontrolsenforced
tolimitaccesstoonlythoseresources
neededtoperformthesupplier’srole.
– Eachresourcethatissharedshould
haveitsownindependentassess-
mentastowhatauthenticationand
authorizationisrequired.Forexample,
staffaccesstoavendor’sdevelopment
projectrequiresadditionalauthoriza-
tionoverandabovetheauthorization
astaffmemberreceivesinorderto
accessavendor’scorporatenetwork.
– Asupplier’saccesstodevelopment
assetsshouldexpireassoonasitleaves
theproject.Afail-safecheckshould
alsobeinplacetoendallprivileges
automaticallyatcontractexpiration
oratanotherfixedperiod.Arobust
procedureisrequiredsothatwhena
supplier’semployeeleavesthesup-
pliercompany,theformeremployee’s
credentialsimmediatelyexpire.A
combinationofautomaticdisablingand
manualnotificationisbesttoensure
completenessofprivilegeremoval.
MalwareScanning
• Suppliercontenttobetransmittedto
thevendorshouldbescannedformal-
wareusingthemostrecentmalware
signaturefilesandmorethanonecom-
mercialscanningengine.Whiletoday’s
malwarescanningtoolsaregenerallynot
designedtoidentifymaliciouscodethatis
perfectlyformed,thisstandardintegrity
controlshouldbeperformedatpointsof
exchangebetweenparties.Depending
ontherelationshipandthepracticalityof
doingso,suppliersshouldinformrecipi-
entsofthecodeastowhatscanninghas
takenplaceuptothepointoftransfer.
SecureStorage
• Sourcecodeforsoftwarecomponents
andproductsshouldbestoredsecurely
withneed-to-knowaccesscontrols
applied.Codepackagesthataretrans-
ferredshouldbemovedtoasecure
assetrepositoryassoonaspracticalso
thattheycanbemanagedmorepre-
ciselywithrespecttoaccessprivileges.
10
CodeExchange
• Processesusingdigitallysignedpack-
agesandverifiablechecksumsorhashes
shouldbeinplacetoensurethatreceived
codeiscompleteandauthentic.Verifying
thedigitalsignatureswithvalidatedtime
stampsofthesoftwarepackagesproves
authenticityandestablishesthatthe
downloadortransferprocessdeliveredan
intactversionoftheintendedpackage.
Vendor Software Development Integrity Controls
Insoftwaredevelopmentandtest-
ing,softwarevendorsbuild,assemble,
integrateandtestsoftwarecomponents
tofinalizethemfordelivery.
Softwarevendorshaveagreatdealof
experienceimplementingpowerfulman-
agement,policyandtechnicalcontrolsto
achievesoundengineeringpracticesand
intellectualpropertyprotection.Thesecure
developmentpracticesthatfocusprimar-
ilyonachievingthe“security”circleinthe
softwareassurancetriaddescribedabove
becomethebaselineforinternaldevelopment.
Withinasoftwarevendor’sorganiza-
tion,additionalsoftwareintegritycontrols
mayexistwithinthecontextofotherIT
functionssuchasbackupandrecovery,
businesscontinuity,physicalandnetwork
security,andconfigurationmanagement
systems.Thefollowingareexamplesof
controlsemployedbySAFECodemembers:
PeopleSecurity
• Itshouldbenotedthatwhilecriminal
backgroundchecksareoftenthefocus
ofpublicdebate,inpracticeSAFECode
membershavefoundthattheyarenotas
effectiveasothercontrolsandprocesses.
Focusingonorganizationalandprocess
controlsinconjunctionwithtechnology
tominimizeriskscomingfromwithinthe
companyismoreefficientandeffective.
Forthatreason,manyofthefollowing
controlstominimizetheriskfrommali-
ciousinsidersarebasedonpractices
suchasthesegregationofdutiesandthe
useofcontrolledautomatedprocesses.
• Itisimportantthatroles,responsibili-
tiesandaccessrightsareclearlydefined
indevelopmentprocessestoachievea
defense-in-depthapproach.Development
managementmustbeknowledgeableas
towhohaswhataccess.Ateamofpeople
withwell-plannedresponsibilitiesmust
maintainappropriateoperationsforguard-
ingcodeassetswhilemeetingthedemands
oftheglobalengineeringenvironment.
Software Sourcing• Procurement
Software Development and Testing• Environment• Personnel• Software Development
Software Delivery• Distribution• Sustainment
11
• Inadditiontotheexpectedtrainingin
securedevelopmentpractices,there
shouldbetraininginthesecuretechni-
calcontrolsusedbyotherintegrity
practices.Doeseachorganizationknow
howtoverifyadigitalsignaturewith
avalidatedtimestamp?Doeseach
organizationunderstandwhichhashalgo-
rithmsarebestusedinachecksum?
PhysicalSecurity
• Buildingsecurityandphysicalaccess
controlshouldbeappliedtodevelop-
mentlocationsandcoderepositoriesand
periodicallyre-assessedusingarisk-based
process.Physicalsecuritycontrolsshould
bestrongenoughtoensurethatdevel-
opmentassetscannotbeaccessedby
outsiders.Physicalprotectionofsource
codeshouldgobeyondasinglelayerof
buildingsecurityandincludeadditional
distinctphysicalaccesscontrolsthatlimit
accesstothosewitha“needtoknow.”
Forexample,additionalbadgerestricted
accessbeyondthenormalbuildingaccess
shouldberequiredforadministrators
toaccesscodeassetsprotectedina
repository.Physicalassetsandcredentials
WhileSAFECode’sDevelopmentPractices
paperdescribeshowtoidentifyandavoid
typicalcodingerrorssuchasbufferover-
flows,SQLinjection,crosssitescripting
andmore,thiscurrentworkdealswiththe
questionofpreservingtheintegrityofan
ITproduct.Theintegritypracticesserve
ascontrolstopreventunauthorizedor
inadvertentchangestothesourcecode.
Withoutpropercontrols,vulnerabilities
canbeintroducedby”goodfaith”develop-
ers.Forexample,whilefixingaproblemin
theirpartofthecodewithdependencies
elsewhere,adevelopermightinadvertently
changecodewhilemergingitwitharelated
function(e.g.,aninterface)primarilyowned
byanother.Withoutproperintegritycontrols,
thischangemightgoundetectedandcould
causeproblemselsewherebecausenobody
wasexpectingthefunctiontohavechanged.
Acombinationofgoodaccesscontrols,
testingandpeerreviewofchangescould
minimizethisrisk.Thusintegritycontrols
canaimatpreservingthewell-constructed
codefortheapprovedspecificationwhile
preventingcarelessorinadvertentchanges.
Integritycontrolsthroughoutthesupply
chainwillalsoreducetheriskofamalicious
attackerbeingabletochangecodeinten-
tionallyorperhapsdetectavirusbeforeit
spreadsintotheproductionenvironment.
Integrity Controls vs. Development Practices
12
(e.g.,keys,badges,securitytokens,
smartcards,laptops,etc.)loanedtoan
individualshouldberetrievedandveri-
fiedagainstalistofexpectedassetsas
partofamanagedterminationprocess.
NetworkSecurity
• Networksecuritystandardsshouldbe
establishedandappliedusingarisk-based
processforthecode-relatedassets.For
example,securityprotectionscouldinclude
intrusiondetectionorotherdefensive
measuresonsourcecoderepositories
withalertingtoappropriateeventsys-
temsthatwouldalarmduringanattack.
Sessiontrafficinvolvingsourcecode
shouldbeencryptedtoacceptablecom-
panyorapplicableindustrystandards.
• Accesstodeveloperworkstationsshould
becontrolled.Forexample,workstations
canbetiedtocorporateauthenticationto
ensurethatterminatedworkersareimme-
diatelydeniedfurtheraccess.Accounts
ofdepartingemployeesandotherautho-
rizedworkersshouldbeproperlydisabled
immediatelytoallowappropriatereviewof
theirwork.Itisimportanttodisable,and
notdelete,accountssothatafullforensic
analysisisstillpossibleaftertermination.
• Workstationandvirtualmachinesecurity
shouldbesecuredtostandardstomini-
mizetheopportunityformaliciouscodeto
beintroducedduringthecodingprocess.
Developersshouldhavewriteaccessto
theminimumcodenecessarytocarry
outtheirresponsibility.Accesstocode
storedonlocalmachinesshouldalsobe
controlledbasedona“need-to-know”and
“least-privilege”basistotheextentpossible
giventhegoalsoftheprojectathand.
CodeRepositorySecurity
• Allcode-relatedassetsshouldbe
housedinsourcecoderepositories
(alsoknownasconfigurationmanage-
mentsystemsorsourcecodecontrol
systems),toenableadditionalatten-
tiontosecurityandaccesscontrol.
• Theserversthathostthesourcecode
repositoriesshouldbehousedsecurely.
Inmostmajorsoftwarevendors,these
machinesarelocatedindatacenterswith
appropriatephysicalsecurity,hardened
serversecurityandbusinessdisaster
recoverycontrols.Bemindfulthatsource
codeissometimescopiedandkeptin
separatedatabasesafterbeingrunthrough
somestaticcodeanalysistools.Theconfi-
dentialityofcodefilesshouldbeprotected
inalllocations.Thisavoidsunauthorized
peoplefromseeingthecodestructure
andtestresults.Combinedaccesstosuch
informationmightenablethemtobetter
targetparticularcodefilesinalaterattack.
• The“outofthebox”defaultsofanysuch
systemmustbeexaminedandconfigured
tobesecurebydefault,ideallyaccord-
ingtoawell-understoodstandardfora
13
systemholdinganacquirer’sprecious
assetssuchasitscustomers’personal
identifiableinformation.Oneobjective
wouldbeforthesystemtooperatewithout
theriskofallowingexploitsthrougheas-
ilyinheritedsystem-levelrootprivileges.
Manydetailedsettingssuchasauthen-
ticationhandling,sessionvariablesand
externalinterfacesmustbeaddressedto
deliversecure-by-defaultdeployment.A
software’sdefaultstateshouldpromote
security.Forexample,softwareshould
runwiththeleastnecessaryprivileges
andservicesthatarenotwidelyneeded
shouldbedisabledbydefaultoronly
accessibletoasmallpopulationofusers.
• Onceenabledassecurebydefault,that
configurationstatusitselfmustbepro-
tected.Asmoresystemslikerepositories
becomecompliantwithspecificationslike
theemergingSecurityContentAutoma-
tionProtocol(SCAP)specifications,the
configurationstateoftherepositoryand
subsequentchangescanbeexpressed
andconsumedinmachine-readable
form,offeringgreaterinitialandongo-
ingprotectionsupportedbyautomation.
• Ideally,accesstosourcecoderepositories
shouldbecontrolledthroughtheuseof
corporateidentitysystems,withstrict
controlmaintainedoveraccesstoany
systemaccount.Engineeringadministra-
torsresponsibleformanagingapplication
repositoriesshouldbenameduserswith
distinctidentitiestoprovideaccountability.
Administrativepracticesshouldobserve
theseparationofdutiesprinciple,and
elevatedpermissionsshouldbesubject
tomanagementapproval.Forinstance,
projectengineeringadministratorsrequire
ahigherlevelofaccesstocodeassets
toperformtheirdutiesthannetwork
securityadministrators.Otherperson-
nelsuchasITorSecurityOperations
mayhaveresponsibilityforbase-level
configurationsandtheoverallplatform
profileincludingsecuritypatchlevels,etc.
• Withintherepositories,accessto
branches,workareasorcodesets
mustbeunderstoodbydevelopment
management,andaccessprivileges
shouldbegrantedusingtheprinciples
ofleastprivilegeandneedtoknow.
• Codesegmentscanbetiedtospe-
cificrequirementsinarequirements
management,enhancementorbug
trackingsystemthatallowsforcross
mappingoffunctionalitytocode.
• Changemanagementpracticeswithreview
andapprovalpathsshouldbeformalized
andwellunderstoodforcodelogicand
assetchanges,repositoryapplicationand
underlyingsystemconfigurationchanges.
• Changelogsforallmodificationstoa
product’scodeassetsshouldbemain-
tainedandpreservedforfutureanalysis.
Logsshouldprovidefilenames,account
nameofthepersoncheckinginthefile,
14
Acompanycanhavesourcecodepolicy
andstandardsthatproductengineer-
ingteamsareexpectedtomeetinthe
contextofprotectingsourcecodeand
productartifactsthroughouttheproduct
developmentcycle.Forexample,these
couldincludedetailedcorporateexpecta-
tionsregardingtheprotectionofsource
coderepositoriesandbuildenvironments.
Somemightbesimplerequirements,like
“SourceCodeSystemsshouldleverage
corporateidentitystoresforauthentication,”
andperhapsobviouslythat“noanonymous
accesscanbeallowedtoarepository.”
Othersaremoredetailed,suchaswhich
particularsystemsforhandlinginternal
requestandapprovalroutingforsource
coderepositoryprivilegesmustbeused
byeachengineeringteam.Settingupthe
linkagebetweensourcecoderepositories
andthesetofbuildtoolsischallenging
sinceautomationandaccountabilitymust
beblended.Apracticalapproachisneeded
suchthatthesetsoftoolscanbeconsistent
andautomated,whilestillmakingitknown
whocreatedandranthescriptedenviron-
mentthatproducedaparticularbuild.In
addition,buildscriptsneedprotectionas
criticalassets.Thisinternalstandardalso
tiesintocorporatesecuritypolicesandcon-
trolssuchasthecredentialingrequirements
forpersonnelandhandlingofdigitalidenti-
ties,akeybridgetobestpracticesaround
theprotectionofsourcecoderepositories.
Anactive,ongoingrelationshipwithengi-
neeringteamsplacestheinternalsecurity
teaminthebestpositiontoeffectongoing
improvementstotheprotectionofcode
throughoutitslifecycle.Therequirements
shouldnotdistractbysimplyattempt-
ingtoforceeveryonetouseanidentical
repository,buttosetthestandardforhow
arepositoryshouldbesetupandoperated
securely.Theapproachtakeninworking
withengineeringteamsistoassessthe
gapsthatexistbetweenwhereagroupis
todayoneachiteminthestandardandto
buildanimprovementplanforclosingthe
gapsaspartofarisk-basedapproach.
15
check-intimestamp,andthelinechanges
made.Theyshouldbekeptforasuf-
ficienttimeinaprotectedenvironment
toassistwithanyforensicsorongo-
ingsecurityimprovementinitiatives.
• Amanifestofallcodeassetscontributing
toaproduct,includingthosedeveloped
in-houseandbythirdparties,shouldbe
maintainedandmanaged,similartoaBill
ofMaterialsinthemanufacturingdomain.
• Versionsofsoftwareassetswiththeir
knownsecuritycharacteristicsshould
betrackedintherepository.Changeor
configurationmanagementshouldbe
trackedaswelltofindthebalancebetween
gettingthelatestpatchesandupdates
andhavingstable,predictablecode.
BuildEnvironmentSecurity
• Buildenvironmentsshouldbeasautomated
aspossible.Thisminimizestheopportunity
forhumaninterventionintheregularbuild
process.However,the“owners”ofthebuild
environmentshouldbefew.Thetraceability
ofactionsonbuildscriptsandofaccess
tocodefilesduringbuildshouldbehigh.
• Buildautomationscriptsshouldbetreated
inamannersimilartoothersource
codeassetsandcheckedintothecode
repository.Thismeansthatchangesto
theautomatedbuildprocesscanbeattrib-
utedtothepersoncheckinginthefile.
• Serviceaccountsthatruninanautomated
fashionbetweensourcecoderepositories
andbuildtoolsshouldbetraceableto
individualswiththeauthoritytoexecute
theautomatedscriptsorprocedures.
Peer Reviews and Security TestingOnesecurityengineeringpracticethatall
SAFECodemembersuseinconjunctionwith
theirsoftwareintegritycontrolsissecurity
testing.Sourcecodeandbinaryanalysis
tools,andsometimesmanualcodereview,
areperformedoncodetoidentifycommon
codingpatternsthatareknowntohave
beenattackedpreviously.Testingtech-
niquesarecontinuallyupgraded.Security
engineeringpracticescomplementsoftware
integritycontrolsbecausesecurityengi-
neeringpracticesrepresentanever-rising
thresholdagainstsoftwaresupplychain
vulnerabilities.Thetestingtechniquesbelow
areprimarilysoftwaresecurityengineering
practices,notsoftwareintegritycontrols.
PeerReview
• Peerreviewsandthemanualinspection
ofcodearenotoftenpopulargivenissues
ofscalability.Automatedtoolscanenable
somescalabilitybycollectingandprocess-
ingmoreartifactsinpreparationforpeers
performingafocusedreview.Also,when
teamsareassignedtoworktogetheron
codefiles,animportantdynamicispresent
wherebyreviewerscanmorereadilyiden-
tifycodethatdoesnotbelongwithinacode
set.Focusingpeerreviewersonchanged
codethatisscannedagainandawaiting
16
approvalduringatwo-stagecheck-into
therepositorycanbeaneffectiveapproach.
Anotherapproachistocouplepeerreviews
inrelationtoexercisedcodepathsinthe
contextofoverallcodecoverage.Ingen-
eral,questionsaboutthestructureand
purposeofsectionsofcodethatarisedur-
ingpeerreviewaremorelikelytouncover
intentionalmaliciouscodeorinadvertent
codeerrorsthanautomatedtestingalone.
TestingforSecureCode
• Thesizeofthecodebaseformanysoft-
wareprojectstodayrequiresautomated
codereviewandtestingtools.Additional
informationonsecurecodetestingcan
befoundinSAFECode’s“Fundamental
PracticesforSecureSoftwareDevelop-
ment”paper.Buildingtheseteststo
runinarepeatableautomatedmanner
increasestheassurancethattheywill
beperformedandanalyzedoften.
• Thelistbelowidentifiesthemostcom-
moncategoriesoftestingtoolsused:
– Staticcodeanalysistools(sourcecode)
– Networkandwebapplicationvulner-
abilityscanners(dynamictesting)
– Binarycodeanalysistools
– Malwaredetectiontools(dis-
coverbackdoors,etc.)
– Securitycompliancevalidationtools
(hardening,dataprotection)
– Codecoveragetools
Whilesecuritytestingisafundamentalpart
ofsupplychainsecurity,softwarevendors
recognizethattestingaloneisnotlikelyto
catchmaliciouscodethatisintentionally
inserted,perfectlycraftedanddisguisedto
appearaslegitimate.Duetotheselimitations,
softwaretestingmustbeaugmentedwith
theotherlistedsoftwareintegritypractices
thatcontrolaccesstodevelopmentassetsto
moreeffectivelyaddresspotentialsoftware
securityrisksinthisstageofthesupplychain.
Vendor Software Delivery Integrity Controls
Thisstageofthesoftwaresupplychain
coversnewproductdeliveryandthe
deliveryofmaintenancepatches.
Itisimportanttonotethatwhilethismay
bethelaststageofthesupplychaindirectly
underasoftwarevendor’scontrol,itisnot
alwaysthefinalstepinthesupplychainfrom
theenduser’spointofview,assoftware
vendorsoftendonotprovidetheirproducts
directlytoend-userorganizations.Inmany
cases,thesoftwarevendor’sproductsare
passedtosystemintegrators,resellersand
authorizedserviceprovidersbeforereaching
Software Sourcing• Procurement
Software Development and Testing• Environment• Personnel• Software Development
Software Delivery• Distribution• Sustainment
17
theend-user.Thus,assoftwarecomponents
leavethesupplier,softwareintegrityand
authenticitybecomeasharedresponsibil-
itybetweensupplierandcustomer.
Publishing and DisseminationThecontrolsforproductdeliveryare
similartothoseforthereceiptofcode
componentsfromsoftwaresupplierstothe
softwarevendorasdescribedintheSourc-
ingsectionofthispaper.However,additional
securityneedsariseoncethesoftware
productiscomplete.Theseincludestate-
of-the-artanti-malwarechecksandthe
availabilityofamechanismthatprovides
awayforcustomerstoassurethemselves
oftheintegrityofthedeliveredpackage.
MalwareScanning
• Productsshouldbescannedformalware
usingthemostrecentmalwaresignature
filesandmorethanonecommercialscan-
ningengine.Asmentionedearlierand
dependingonthenatureoftherelationship,
itmaybeappropriatetocommunicatewhat
scanningwasdonepriortothehandover.
CodeSigning
• Thesoftwarevendor’sproductshouldbe
stronglydigitallymarkedwiththesoftware
vendor’sidentityinawaythatcan’tbe
altered,yetmaybeverifiedbycustomers.
Delivery
• Avendor’sprocessfordelivering
productsbothonlineandthroughdis-
tributionsusingphysicalandelectronic
mediashouldbesecured.Informa-
tiononcodesigningandchecksums
shouldbeavailabletocustomers.
Transfer
• Transferproductsinsuchawaythatthe
receivercanconfirmthattheproduct
iscomingfromthesoftwarevendor.
Authenticity ControlsForalltheworkthatsoftwarevendorsdo
inensuringtheyproduceaqualityproduct
freefromvulnerabilities,thereremains
residualsupplychainriskaftertheproduct
hasbeenreleased.Millionsofcustomers
everyyearunsuspectinglyacquirecoun-
terfeitsoftware.AccordingtotheBusiness
SoftwareAlliance,overoneinfivesoftware
packagesarecounterfeitorpirated.2
Whilenotacentralfocusofthis
paper,authenticityoranti-
counterfeitingcontrolsare
oneofthethreeessential
elementsofsoftware
assuranceandthus
aretightlyintegrated
withsoftwareintegrity
controls,especiallyas
2.BusinessSoftwareAlliance,“SixthAnnualBSA-IDCGlobalSoftwarePiracyStudy,”May12,2009.
Integrity
ASSURANCE
Security
Authenticity
18
softwareispreparedfordelivery.Thus,it
isimportanttohighlightthekeyauthentic-
itycontrolsusedbysoftwarevendorsinthe
softwaredeliverylinkofthesupplychain.
Counterfeitproductsoftenlookauthentic,
buttheyposeseriousriskstocustomers.
Counterfeitsoftwarecannotbeassuredto
functionasintendedandoftencontains
maliciouscodeaimedatdatadestructionor
theft.Protectingcustomersandbusinesses
fromtherisksofcounterfeitsoftwarerequires
bothengineeringeffortsbysoftwarevendors
andawarenessandrecognitionbyacquir-
ersandendusers.Theriskofcounterfeit
softwarecanbegreatlyreducedthrough
purchasefromonlyauthorizedresellers,
carefulexaminationofproductpackagingand
media,andtechnologytonotifyuserswhen
theymaybevictimsofcounterfeitsoftware.
CryptographicHashedorDigitallySignedComponents
• Asmentionedabove,digitallysigned
componentsorchecksumhashesarean
essentialauthenticitycontroltoprove
thatcomponentsaregenuine.Withany
systemtherearecharacteristicsofthe
softwarebeingshippedthatarestable,
whiletheremaybeotheritemsthatvary
withparticularconfigurationoptions
asinstalled.Todaythe“signing”ofan
applicationprovidesacapabilitytodetect
thatanapplicationhasnotbeentam-
peredwithsincethetimeitwassigned.
Vendorsmustfindtherightbalanceand
offerproofofauthenticityforthemany
predictableaspectsofthesoftware.
NotificationTechnology
• Withavarietyofdistributionchannels
forsoftware,includingonlinedistribution,
customersoftencan’ttellthattheyhave
acounterfeitproductuntilitisinstalled
ontheircomputer.Vendorscanleverage
technologytodetectcertainaspectsof
theproduct’sintegrityandnotifytheuser
ifthesoftwareisdeemedtobecounter-
feit.Sometimesintroducedbyvendorsto
preventlicensepiracy,thistechnologyhas
evolvedintoaneffectiveintegritycontrol.
AuthenticVerificationduringProgramExecution
• Inpractice,theintegrityofanapplica-
tioncanbeverifiedwhentheapplication
isinstalledonacomputer.Additionally,
eachtimeanapplicationrunsonauser’s
computer,similartechnologycanverify
theintegrityofthefilesthatmakeupthe
application.Thehardwareandsoftware
technologyusedtoverifytheclaims
applicationsandfilesmakeabouttheir
validityandintegrityiswellunderstood,
efficientandbroadlyavailable.Software
vendorswhoalreadymakeuseofthis
technologyhaveinvestedinhardware,
software,peopleandprocess,effec-
tively“codesigning”theirapplications.
19
• Avendorwiththerighttechnology
toolscaneffectivelypre-authorizethe
programexecutionofonlyaspecific
setofapplicationsfroma“good”list,
effectivelyblockinganynewlyspawned
codethatmaynotbelegitimate.
Product Deployment and Sustainment in the EcosystemThesoftwarelifecycleextendsbeyonddelivery
oftheinitialsoftwarevendor’sproductand
intotheproduct’ssustainmentormainte-
nancephase.Asaresult,patchesandhot
fixesshouldbesubjecttothesamesoftware
integritycontrolsastheoriginalcode.
Itisimportantthatauthorizedserviceperson-
nelwithongoingaccesstogenuinepartsand
properdisposalproceduresareinvolvedin
thesustainmentprocess.Authorizedaccess
shouldconveythatthepersonactivelyworks
forthecompanyprovidingtheserviceand
thatservicepersonneldon’thavemore
privilegesontheinstalledenvironmentthan
thoseneededtocompletethetaskathand.
Allservicetransactionsshouldprovideevi-
dencethatlegitimateservicepersonneldid
thework,andevidenceshouldbeavailable
forauditandprotectedagainsttampering.
SecureConfigurations
• Wheneverpossible,softwarevendors
shouldshipproductswithasecure
configurationbeingsetasthedefault
configuration.Secureconfigurationsforthe
suppliedsoftwareshouldbedeliveredto
thecustomeralongwithanoutlineofthe
riskimplicationsoftheconfigurationstate
orchoicesdetailed.Thefutureofbroader
adoptionofmachinereadableSCAP
compliantconfigurationswillstrengthen
thisarea’scontributiontointegrity.
CustomCodeExtensions
• Softwaredesignedtobeintegratedand
extendedtodeliveradditionalfunctionality
createsanotherlinkinthesupplychain.
Assumethattheoriginalsoftwareandits
interfacesweresecure,fullyfunctional
anddeliveredwithintegrityandauthentic-
ity.Softwarecomponentsthatareadded
latertoextendthefunctionsofanIT
Systemmustbealsobetreatedwiththe
samecareasoriginallyappliedbythe
internaldevelopmentandtestingofits
supplier.Integratorsmustfollowsecure
developmentpracticesastheyextend
codefunctionalitythroughtheprovided
secureinterfaces.Inaddition,tocontinue
integrity,theircomponentassetsshould
becatalogedinarepository,accessto
coderestrictedbasedon“need-to-know”
andpeerreviewsimplemented.The
chainofcustodymustbepreservedwith
thesecontrolsasthesetsofproducts
areassembledforthesolutiontobe
deliveredtotheultimateendcustomer.
Resellersorsystemsintegratorsoften
managethislinkinthesupplychain.
20
Table1:SummaryofSAFECodeSoftwareSupplyChainIntegrityControls
Processes Controls
Softwaresourcing
Vendorcontractualintegritycontrols
•Definedexpectations
•Ownershipandresponsibilities
•Vulnerabilityresponse
•Securitytraining
Vendortechnicalintegritycontrolsforsuppliers
•Securetransfer
•Sharingofsystemandnetworkresources
•Malwarescanning
•Securestorage
•Codeexchange
Softwaredevelopmentandtesting
Technicalcontrols
•Peoplesecurity
•Physicalsecurity
•Networksecurity
•Coderepositorysecurity
•Buildenvironmentsecurity
Securitytestingcontrols•Peerreview
•Testingforsecurecode
Softwaredeliveryandsustainment
Publishinganddisseminationcontrols
•Malwarescanning
•Codesigning
•Delivery
•Transfer
Authenticitycontrols
•Cryptographichashedordigitallysignedcomponents
•Notificationtechnology
•Authenticverificationduringprogramexecution
Productdeploymentandsustainmentcontrols
•Patching
•Secureconfigurations
•Customcodeextension
21
Future DirectionsAssoftwareintegrityremainsanemerg-
ingdiscipline,thereareanumberof
areasthatSAFECodebelievesdeserve
furtherstudyandindustrycollaboration.
Theseinclude,butarenotlimitedto:
SupplierManagementandCommunicationalongtheSupplyChain
• Theworkthatthesoftwareindustryhas
undertakentoidentifyandimplement
securecodingpractices,includingthe
findingspresentedinSAFECode’s“Fun-
damentalPracticesforSecureSoftware
Development”paper,takesonnew
implicationswhenexaminedalongthe
supplychainfromonesuppliertoanother.
Thesesecuritypracticestogetherwith
normalqualitycontrolconcernscould
bereexaminedinthecontextofthe
exchangeofsoftwareandrelatedinfor-
mationfromonesuppliertoanother.
ResearchonSoftwareTesting
• Asdiscussedpreviously,automatedtest-
ingcurrentlyislimitedinitsabilityto
detectmaliciouscodethatisintentionally
insertedandwelldisguisedaslegitimate.
Essentially,todayautomatedtestingcan
onlydetectmalwarethatusecoding
patternsthathavebeenseenpreviously.
Increasingthecapabilityofsoftwaretest-
ingofsourceandbinarycodetoidentify
vulnerabilitiesisanareaworthyoffuture
researchanddevelopment.Additional
behavioralanalysisofapieceofcodemight
beapromisingnewapproachsimilarto
whatisalreadyimplementedinsomeof
today’santi-virusdetectionsoftware.
AuthenticityEaseofUse
• Whilecryptographycanbeappliedwith
checksums,digitalcertificatesandsigna-
turesandvalidatedtimestamps,theuser
experiencetoverifylegitimatesoftware
canbeconfusinganddaunting.Usersneed
fareasiermeansofvalidatingauthenticity
sothattheyarenotprimarilyfocusedon
clearingtheirscreensofanydistractions
togetonwiththetasksathand.Since
socialengineeringattackssometimescount
onusersdismissingwarningsorerrors,
ongoingworkinthisareaisimportant.
AuthenticSoftwareatRuntime
• Howcanend-usersassurethemselvesthat
allsoftwarerunningontheirmachinesis
authenticandtrustworthy?Onepromising
technologyadvancementistheTrusted
PlatformModule(TPM),ahardwarecompo-
nentthatcanbeintegratedwithasigned
operatingsystem,signedapplicationsand
signedadd-instoprovideanenduserthe
assuranceatruntimethatallcomponents
areauthentic.However,forTPMstobe
trulyeffective,allsoftwaremustbesigned.
Somevendors,bothcommunity(open
source)andproprietary,havetakensteps
toenablethistechnology.However,an
22
industry-wideeffortisnecessarytoachieve
thisvisionasthecomputersusedbyend
userscontainaneclecticcollectionof
softwaresourcedfromavastecosystemof
vendors,suppliersandcommunities.The
TrustedComputingGroup(www.trusted-
computinggroup.org)isanexampleofan
organizationactivelyaddressingthisissue.
MoreComprehensiveDataonToday’sPracticesandControls
• WhileSAFECodehasofferedthebest
thinkingofitsmembercompaniesinthis
importantemergingarea,thefieldcould
befurtheredbycapturingbroaderdata
fromalargersegmentofinformation
technologyvendorsabouttheircur-
rentorpreferredpracticessothatthe
overallcommunityisguidedbydataas
continuousimprovementsaremade.
SoftwareIntegrityandCloudComputing
• Theimpactofcloudcomputingonthe
“traditional”viewofsoftwaresupply
chainrisks,asaddressedinthispaper,
needstobeassessed.Softwarepos-
sessesmanyofthesamecharacteristics
inherentinotherformsofintellectual
property.Asaresult,issuesassociated
withjurisdiction,accessauthorizationand
complianceneedtobeassessedfortheir
impactonsoftwareintegritycontrols.
BroaderCollaborationwithSupplyChainManagementCommunity
• Whilethewell-establishedandmature
supplychainmanagementcommunity
isbecomingawareoftheseemerging
threatstotheITsystemsupplychain,
thereisroomforgreatercollaboration
aroundasharedunderstandingofthe
challenges,commonterminologyand
existingdisciplinesthatcanbeleveraged
acrossanevenbroadercommunity.
Measurement
• SAFECodeiscurrentlyexaminingitsmem-
bers’practicesonmeasuringsoftware
assurance.Asthatworkevolves,there
aresuretobeimplicationsforimprov-
ingtheexchangeofintegrity-related
measuresamongtradingsuppliers.
23
ConclusionSAFECodeviewssoftwareintegrityasa
fundamentalpillarofsoftwareassurance.
Protectingtheintegrityofsoftwarerequires
asetofcontrolsthatshouldbeimplemented
alongsidesecuredevelopmentandauthentic-
itypractices;indeed,integritypreservesand
supportssecurityandauthenticityacross
thecomplexityofasupplychain.However,
resourcesandbestpracticesforidentifying
andanalyzingsoftwareintegritycontrolsare
notyetwidelyavailable,creatingchallenges
forbothsoftwarevendorsandcustomers.
Whileasoftwarevendorisonlyonelinkin
acomplexITsolutionsupplychainandhas
alimitedabilitytoinfluencetheactionsof
theotherentitiesalongthechain,allsoft-
warevendorshaveboththeopportunityand
responsibilitytoprotecttheintegrityofthe
softwareasitmovesthroughthelinkthey
control.Thisrequirestheapplicationofsoft-
wareintegritycontrolstoavendor’ssoftware
sourcing,developmentanddeliveryprocesses.
SAFECodebelievestheindustry-wideadoption
ofsoftwareintegritycontrolshasthepotential
togreatlyimprovecustomerconfidencein
ITsystems.Ithaspublishedthiscollection
ofbestpractices,whicharebasedonthe
lessonsitsmembershavelearnedintheir
individualimplementationofthesecontrols,
inanefforttoprovideguidancetoothers
intheindustry.SAFECodeencouragesthe
softwareindustrytotailorandadoptthese
controls,aswellascontinuefurtherstudyand
analysisonadditionalpracticesandcontrols
toimprovesoftwaresupplychainintegrity.
AcknowledgmentsBradArkin,AdobeSystemsIncorporated
EricBaize,EMCCorporation
MattColes,EMCCorporation
RobertDix,JuniperNetworks,Inc.
YuecelKarabulut,SAPAG
PaulNicholas,MicrosoftCorporation
GaryPhillips,SymantecCorporation
TysonStorch,MicrosoftCorporation
KevinSullivan,MicrosoftCorporation
JanneUusilehto,Nokia
About SAFECodeTheSoftwareAssuranceForumforExcellence
inCode(SAFECode)isanon-profitorganization
exclusivelydedicatedtoincreasingtrustininfor-
mationandcommunicationstechnologyproducts
andservicesthroughtheadvancementofeffective
softwareassurancemethods.SAFECodeisaglobal,
industry-ledefforttoidentifyandpromotebest
practicesfordevelopinganddeliveringmoresecure
andreliablesoftware,hardwareandservices.Its
membersincludeAdobeSystemsIncorporated,
EMCCorporation,JuniperNetworks,Inc.,Microsoft
Corp.,Nokia,SAPAGandSymantecCorp.For
moreinformation,pleasevisitwww.safecode.org.
©2010SoftwareAssuranceForumforExcellenceinCode(SAFECode)
(p)703.812.9199
(f)703.812.9350
(email)stacy@safecode.org
www.safecode.org
SAFECode
2101WilsonBoulevard
Suite1000
Arlington,VA22201