Document ISO/IEC/JTC 1/SC 22/WG 23 N0569

Draft Agenda Meeting #38
ISO/IEC JTC 1/SC 22/WG 23: Programming Language Vulnerabilities
17-18 September 2015

Meeting Location :

INCITS, 1101 K St NW, Washington, DC 20005, USA

Meeting Times:

17-18 September 2015: 0900-1700 EDT (1300-2100 UTC)

Local Arrangements:

Please see document N0567 Local Arrangements for SC 22/WG 23 Meeting 38.

Local Contacts: David Keaton <>


Teleconference Info

SC 22/WG 23 Meeting 38
Every day, from Thursday, September 17, 2015,

to Friday, September 18, 2015

9:00 am  |  Eastern Daylight Time (New York, GMT-04:00)

8 hrs 

Join WebEx meeting

Meeting number: 954 560 185

Meeting password: wg23

Join by phone

0800-051-3810 Call-in toll-free number (UK)

+44-203-478-5289 Call-in toll number (UK)

Access code: 954 560 185

Global call-in numbers

Toll-free calling restrictions

Add this meeting to your calendar.

Can't join the meeting? Contact support.


1 Opening activities

1.1 Opening Comments

1.2 Introduction of Participants/Roll Call

1.3 Procedures for this Meeting

1.4 Approval of previous Minutes

1.5 Review of actions items and resolutions, Action Item and Decision Logs

1.6 Approval of Agenda [N 0578]

1.7 Future Meeting Schedule








November 2016

October 2016

TBD Sep 2016

TBD June 2016

TBD May 2016

April 14-15



With SC 22 Plenary

Face-to Face, location TBD

Teleconference (UTC 2000, 2 hr)

BSI, London UK, with SC 22/WG 14




7 March 2016

8 Feb 2016

11 Jan 2016

Teleconference (UTC 2100, 2 hr)

Teleconference (UTC 2100, 2 hr)

Teleconference (UTC 2100, 2 hr)




Teleconference (UTC 2100, 2 hr)



Cancelled as a P2P meeting. Teleconference?

2. Liaison Activities

2.1 SC 22

Subcommittee completed its 2015 Plenary on Tuesday 15 September 2015. WG 23 requested a formal project split of 22.24772 into 9 parts: Part 1 Language Independent; Part 2 Ada; Part 3 C; Part 4 Python; Part 5 Ruby; Part 6 Spark; Part 7 PHP; Part 8 Fortran; and Part 9 COBOL. The resolution for this item (15-07) passed unanimously.

WG 23 further requested that TR 24772-1, -2, -4 and -8 be commenced immediately, with a 36 month target date for publication, and a scope and editor assigned. The resolution for this item (15-08) passed unanimously.

2.2 PL 22 (Open)

2.3 PL22.3/WG5 (Fortran)

2.4 WG4 (COBOL)

2.5 WG9 (Ada)

2.6 PL22.11/WG14 (C)

2.7 PL22.16/WG21 (C++)

2.8 Ecma International, TC49/TG2 (C#)

2.9 Ecma International, TC39 (ECMAScript)

2.10 MISRA (C)

2.11 MISRA (C++)

2.12 SPARK

2.13 SC7/WG19 (UML)

2.14 SC27/WG3, WG4 Security

2.15 Other Liaison Activities or National body reports

3. Document Review

3.1 DIS 17960 Code Signing

3.2 TR 24772-1 Vulnerabilities, language independent

Review document N0565

3.3 TR 24772-2 Ada language specific part

Document is in hands of WG 9 for updates.

3.4 TR 24772-4 Python language specific part

Review document N0558 Python language vulnerabilities contributed by Santiago.

3.5 TR 24772-8 Fortran

Review document N0560 Fortran language specific vulnerabilities

3.6 TR 24772-3 C

Review document N0580 which is an edit (from Stephen Michell) of N0554 for C language specific vulnerabilities contributed by Clive Pygott. Can we add any vulnerabilities for concurrency?

3.7 TR 24772-X C++

As available

3.8 Standing Document 6

Review newly created SD 6 for correctness and formatting.

4 Strategy (Face to face meetings only)

At an earlier meeting, it was recommended that we consider developing programming standards to avoid section 7 (design) vulnerabilities. A discussion is needed as to what format such document(s) would take, what level of assurance they should target, i.e. scope, goals. Before going too far, should we draft an outline of a sample standard (or technical specification)?

An idea was presented this week to mine the guidance to user sections for common guidance, and to create a top N (N=10, N=25, etc) guidances that can be used by people creating programming guides. A reasonable place to put such guidance would be in section 5.

We have an issue with moving to ISO eCommittee, in that people that contribute that are not registered as NB experts get unequal access to documents. Other committees do not use the N-numbering system the way that we have. They use the N-numbers for official (process) documents such as minutes and agendas, and for product versions ready for ballot. All other documents are “informal”. Would such a process work for us? We could set up a CVS or a GIT system where it is easy and reliable to identify versions of a document as it is edited.

5 Publicity (Face to face meetings only)

6 Other Business

6.1 Review of Assignment of responsibilities

7. Resolutions and Action Items

8. Adjournment